RSS

Tag Archives: agile

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: , , ,

Would the real ‘Agile’ please stand up!

16 Jul

I’m not a fan of rap but I do like Slim Shadey(sp). I decided to see what wikipedia had to say about Agile and when I got there I was very surprised. First of all I was expecting to see something that mirrored the Agile Manifesto. What I mean is that when the wikipedia page rendered on my phone the first thing I saw was a drawing/poster of the Agile process and (a) the vocabulary did not look like it came from the Agile Manifesto but (b) from waterfall.  In fact, while I have been saying this for some time… it is now fully realized.

The “Agile Software Development” process or whatever you want to call it is actually a modified “Waterfall”. (It even looks a lot like RUP too.

Please do me a favor. Stop calling it Agile because it is not. Agile and the Agile Software Development are two completely different things.

Finally, just because your development team practices the Agile [new name goes here] Software Development process does not mean that your entire management structure needs to be flattened. Neither Agile nor ASD recommend anything beyond “the team” of developers. Of course you might trat your managers as a team in sort of a breadth first search sort of way. But to suggest that self organizing teams should be left completely to themselves is just irresponsible. Simply put mob wisdom does not always work; specially when it’s my money on the line.

 
Leave a comment

Posted by on 2012/07/16 in agile

 

Tags: , , ,

Agile Manifesto – Agile Rails – the proof

21 Apr

Typically in a scientific endeavor if just one component of the proof turns out to be false or unprovable then the entire  endeavor is considered a failure. This is not the same in software development. The successful parts are kept and the failures are deleted.

But this brings me to the point. The author of Agile Web Development with Rails Fourth Edition (pragprog) quotes the Agile Manifesto and then draws an inference with Rails.

“Individuals and interactions over processes and tools” –Agile Manifesto

and then …

There are just small groups of developers, their favorite editors, and chunks of Ruby code. –Agile Web Development

and then all was lost…

“Working software over comprehensive documentation” –Agile Manifesto

You won’t find 500-page specifications at the heart of a Rails project. –Agile Web Development

The “problem” here is that is assumes that everyone is an expert; everyone is performing to the same level all the time; that there is no attrition on the tech or business side; and that people never get bored in their jobs.

It’s nice to say that everyone can look at a SHA-512 function and determine what and how it works from the function prototype and the code… as easily as they would understand a hello world. That is simply not the case. The existence of the SHA-512 is based on a rigorous mathematical proof that is akin to the 500 pages of requirements.

I recently tweeted that I could not imagine the construction crew of the Empire State Building or the Brooklyn Bridge completing their projects without (a) a requirements doc (b) a blueprint or two.

The Agile group can work on small and less complicated projects but once you get to a certain scale in complexity or Mythical Man Month scale then Agile is the real myth.

 
1 Comment

Posted by on 2012/04/21 in agile, architecture, management

 

Tags: , , ,

The Agile Manifesto

13 Oct

from thinkgeekIf you are really hell bent on going down the Agile footpath then I urge you to read the Agile Manifesto.  Then throw everything else in the trash.  The manifesto makes common sense and frankly if you need the other books, references, and cheatsheets. The you probably don’t get it and you should look into another career.

I know this is a harsh thing to say and commit to a blog but it you think about it for just a moment and you clear your head of all of the hubris that you hold for Agile … you’ll come to the same happy place and realize your glass is half full and you’ll still be able to do your work but you won’t be generating heat doing agile to the agile process.

There is a whole world out there and while your dedication to a “thing” is admirable. I might just be a waste of time.

 
Leave a comment

Posted by on 2011/10/13 in business, 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