RSS

Tag Archives: scrum

Are Story Estimates Valuable?

26 Sep

Whether you’re implementing KanBan, Scrum, or Agile Process Management the topic of estimates is always brought up. The question on my mind is whether there is any real value in making an estimate and /or being accurate. Clearly there are opportunities to game the system.

On the other hand what value do they bring to the stakeholders? They are going to set the timeframes based on the need of the feature and not how long it’s going to take (although that can play a minor role). And then there is the project management and leadership who is going to review the numbers. But what does it mean to them and what are they going to do with it?

Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I’d have this analysis done in an hour.
Scotty: How long will it really take?
Lt. Commander Geordi La Forge: An hour!
Scotty: Oh, you didn’t tell him how long it would *really* take, did ya?
Lt. Commander Geordi La Forge: Well, of course I did.
Scotty: Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker.

The bottom line: (a) stakeholders set the priorities. (b) stories are supposed to have known resource costs whether your sprint cycle is a day, week or month (c) daily reviews(standups) and periodic retrospectives are supposed to contain actual effort. So to ask for estimates is just false.

 
1 Comment

Posted by on 2012/09/26 in agile

 

Tags: , , ,

Standup Meetings: Scrum vs KanBan vs Agile vs Other

25 Sep

Everywhere you go these days teams are doing some sort of standup meeting. Whether it’s rigorous, loose, or even adhoc they are doing it.

  • KanBan

In the KanBan standup meeting the team is supposed to take a task centric view. That means (a) blocking tasks, (b) tasks that are risky, (c) tasks that have not made any change since the last time, (d) whatever’s left.

  • Scrum
  • Agile

On the otherhand, Scrum and Agile take a resource centric view. Going from contributor to contributor… answering the questions (a) what I did yesterday, (b) what I an doing tomorrow, (c) what is blocking progress.

  • Other

Between the Agile/Scrum and KanBan they pretty much have things covered. I imagine that if anyone were to invent a new process it might look exactly like these with variations on time, scheduling, attendees, subject mater and/or magnification. So other is my catch all.

One other thing to mention is that sometimes the teams are cross functional and so the stand ups take place twice. Once in the cross functional team or cell and again in the vertical talent pool. And finally, at some point when the project is big enough the updates need to be escalated to the next level so that the information can be aggregated and the stake holders engaged to make critical decisions if necessary.

In conclusion they all have something to offer. Whether your team is going to benefit depends on the team, the mission, support and needs from leadership and stakeholders. Knowing what and how to communicate; and how to summarize and report are key to success. Let’s not forget that feedback is an important part of the cycle too.

 
Leave a comment

Posted by on 2012/09/25 in agile, management

 

Tags: , , ,

Scrum – always better to go first

23 Feb

I remember in (elementary, middle, high, college, university) school that I hated to go first. It did not matter what it was I just hated it. Think of it as the leadoff hitter in baseball. (which turns out to be a good place to be)

What I just realized, after being on a scrum call with my client and their entire development team, is that I want to go first. By going first there is a psychological edge that you are the one that everyone else if following. If someone says that they implemented ‘X’ and you also implemented ‘X’ it’s better to be #1 instead of +1.

In today’s call it appears that the code is forking and efforts are being duplicated. #1 might be tasked to continue as-is where +1 will likely be seen in a me too position and that person is likely to be reassigned.

So unless you do not like your work… be #1.

The same can be said for bad news but that’s a story for another day.

 
5 Comments

Posted by on 2012/02/23 in agile, management

 

Tags:

Agile is still dead and has been since 1991

30 Sep

[updated 2011.09.30] yet another response to Agile is good.

When you have so much of you career invested in something like Agile, XP etc… it can be hard to see the forest for the trees. I had a consulting job in The Haag many years ago. IBM was the incumbent contractor at the customer site (a bank) but after 5 years on the job they had not written a single line of functioning code. In the office there were two teams of software people… both behind closed doors. The first team was the Data team and the second team was Functional. They rarely spoke and they never shared information. I was there for a week, introduced the client to OO and we had a functioning prototype. Smart people do smart things, You cannot make an underachiever exceptional by using Agile. Either they get “it” or they don’t.

I just commented on a blog. I’m sure there is some validity to his post beyond observing that Agile Scrum is broken. It certainly is not what it was originally intended but for that you have to go way back to Dave and Andy from PragProg. I have not found the original links and references myself but I recall enough from my reading at the time. Today’s Agile does not look anything like what it was.

Scrum deflects from individual accountability. But the failure of agile/scrum is probably more psychology than technology. There are essentially three groups of people. 1) the high achievers that you want everyone to emulate; 2) the average devs; 3) and the low achievers. The high achievers hate these processes because it simply adds friction to their day. The low achievers love it because it deflects individual responsibility (think Survivor or Big Brother; the best do not always win. Floater is a legitimate strategy). And the average achiever is ambivalent and can be tipped either way.

Everyone is different and creative in their own way. You cannot herd cats with agile or scrum.

Agile does not treat people with respect. It dictates with strict rules what and how things are to be done. When the reality is that we have individual and collective responsibility. And most of that is encapsulated in an unwritten “bill of rights” that we carry around with us. At least the high achievers do. Translating that BOR to everyone else with a wide brush is simply too general an approach. Improvement from the under achievers comes from training, education, and more then anything else experience and experience from making mistakes.

The real chalenge here is that businesses are trying to grow their ranks as fast as they can. Many times that means hiring people that they would not hire if there was not such a shortage. This is a different set of problems from Agile and Scrum. This problem can be fixed by being selective, selecting people with aptitude for the work, selecting tools that lower the bar of entry, and managing people rather then allowing them to manage themselves.

 
8 Comments

Posted by on 2011/09/30 in business, management

 

Tags: ,

Agile Management vs Herding Cats

09 Sep

I recently blogged about agile, building teams and herding cats. It’s a topic that’s always close at hand. I’ve had several job interviews over the last 4 months and agile always comes up.

Agile used to mean the tight feedback loop between the client and the producer (the producer can be a programmer). Today it has come to mean so much more.

I asked an agile coach, friend of mine, about the cats and agile thing. His response was that you cannot heard programmers like cats. And that you had to have strong leadership and define clear goals.

So I went back to my Agile Project Management book and started thumbing through. I found a passage where the author said that teams were meant to be self organizing.

All of the contradiction is making my head spin.

Agile Suggests:

  • there are no managers
  • that the teams might be made up of cats, but so what, they will self organize
  • priorities are set by project managers who manage projects and not people
  • producers don’t have to make value decisions just do the work

But my friend suggests that:

  • you need a strong manager
  • clear goals (probably priorities)
  • don’t bother with the cats, that’s so yesterday

hmmm… So I skimmed my Scrumban and Kanban books again; looking for references to teams. The common “self-organized” statement was there… but that was it. And then Eureka.

Agile Project Management is meant to be implemented by strong and seasoned managers. Managers who already heard cats at an intuitive level. And so my blood pressure is resuming it’s normal level as I recognize the fact that strong/good managers already herd cats and probably to agile on the fly by intuition; where new PMI, paper dragons, rely on the strictest sense of the “written” agile process instead of a functional blend between project management and people management.

PS: Many years ago I took a class on “root cause analysis” that was being given by a consultant for my employer. Root cause is pretty easy to do; it’s essentially a recursive investigation into the mathematical significance in the problem/error space. The instructor was clear to say that noobs should recurse down all paths until the numbers were flat. And more importantly leave intuition out of it. Your intuition will work but later. This was practical advice because “we” were always in the data. Day-in, day-out. This is different than management. There is room for intuition in people and product management. But you need “strong” skills to be there.

Agile is ok. I’m certain it works. But it should not be the only tool in the managers toolbox. Teams, people and projects are much more complicated than this. Otherwise the ten commandments would have been enough.

 
2 Comments

Posted by on 2011/09/09 in management

 

Tags: , , , ,

 
One Page Docs

Creating a library one page at a time.

One Page Bugs

Reducing the friction of writing and fixing bugs or features.

Follow

Get every new post delivered to your Inbox.

Join 223 other followers