Archive for January, 2010

I come to believe that most product development environments and processes are just to damn confusing. Not by nature, but manmade. Let’s look at bug tracking. I’ve spent too many hours of my live with QA and product managers to prioritize a list of bugs.

P1, P2, P3 and P4.

P1 and P2 need to be fixed ASAP because you cannot ship the product with them. Tough luck for P3 and P4 as they probably will rot in the system as there are too many P1/2.

Now let’s look at a classical scenario. Programmer A writes code for two weeks to implement feature F for product P. Once he is done — it works on my machine — he reports to his manager and moves on to the next task. Meanwhile the testers are busy testing another product S for two more weeks. Then, after two weeks, tester T looks at feature F and discovers some issues. Let’s say four of them. Two are bugs, one is a requirement misunderstanding from tester T and the last one just a minor cosmetic thing, a spelling mistake ‘Tset’ instead of ‘Test’. After three days T is done logging all issues in the issue/bug tracking system.

P receives per mail the list of bugs but ignores them as he has to finish another feature. The following week he is done and addresses those issues. The spelling mistake is fixed easily, it takes him only 20 minutes in total. The two bugs are more tricky especially since 3 weeks have past since the implementation and the code is not fresh in mind any more. It takes some time to isolate the problem and fix. 4 hours for either. Now, the requirement misunderstanding. He reads the description again and again and is sure that the current implementation is right. So he amends the entry for further clarification and emails — ping-pongs — T.

The next day T looks at the request for more details and, after some mental swearing, adds more details and ping-pongs the bug back to the developer.

P is busy for another two days finishing up another feature and then looks at the bug again. After two hours he is sure that T is mistaken and puts his conclusion in the system. Ping-Pong once more. T reads the reply the next day and actually agrees with P. He sends an email to M the product manager asking for clarification. Luckily, M works long hours and forwards the email at midnight to S the subject matter expert. After two days S replies to M who forwards the clarification to T who puts it into the system and pushes it back to P. Ping-Pong. As it turnes out P was right but not completely so he needs to make one minor change and send it for a final review to T. T looks at it the following week as she is busy working on another product. Six days later T runs a final test and checks it off as complete.

Wow, what an amazing game of Ping-Pong. Corporate Ping-Pong.

Let’s analyze it quickly. The whole implementation and testing circle lasted for over 8 weeks. It is driven by the wrong believe that working in batches and specialized silos makes us more efficient. 100% workload equals to 100% productivity. This is plainly wrong.

How would Agile have handled it. I will give a short description using Scrum as the method. First you work in time boxes which are fix, you don’t ever make a sprint longer or shorter. (You can adapt sprint length but usually you plan it ahead; also this is often a sign of ScrumBut). In each of those sprints you deliver value to the customer in the form of running and usable software. Being 80% done does not cut it. It is either all or nothing. The Product Owner specifies what she wants ahead and the development Team estimates how much can be done in one sprint. Once the feature set is decided the acceptance criteria are defined with the product owner. Until those are met there is no chance the product owner will accept the feature. Actually the acceptance criteria are only one point in the Definition of Done. The Definition of Done — DoD in short — can include all kinds of requirements to be met. Popular are, automated Unit Tests (Verification) and Story Tests (Validation) for all code. If working in a regulated environment, often the DoD also includes the required Documentation.

Next, in Scrum there would not have been two different departments. The team is co-located and cross functional. In our case P, T and M would have been in the same room. M might not be there all the time but a couple of hours each day. So, the corporate ping-pong would not have taken place at all. The typo bug would have taken 2 min without the entire bug tracking system overhead. The fixing of the bugs less then the 8 hours. Let’s say 6 hours as the code was still fresh in mind. Finally, the requirement misunderstanding would have lasted not more then 3 days at most. P and T would have discussed it side by side for about 1 hour and then spoken directly to M. Assuming that S still takes 2 days, the 3 days are rather generous.

Altogether we are looking at two weeks, the length of the sprint. Compare this to the 8 weeks in the high productivity setup. Slack, for some people this words is associated with very bad things. In agile, you need some slack to be able to react fast without too much task switching. A good book about this topic is Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.

Actually, I’ve started to throw out the bug tracking system altogether. It is just too much waste. Don’t allow bugs by building quality in. Whenever a bug pops up, it is being addressed immediately. This might look counter productive but in the long rung it speeds you up. I like to use this metaphor; a bug is like a whole in the road. So getting from A to B gets slower the more bugs you have. In order to go fast you need to improve the road condition by fixing the bugs. Once you have a state of the art road condition, you can move at high speed continuously as upcoming wholes – bugs – get fixed immediately.

I like Sports but not Corporate Ping-Pong!

The future is lean agile!

Read Full Post »

Agile EVM

Today, I was asked by a colleague how to control costs and schedule in SCRUM projects. Well, I’m a friend of earned value management (evm), explained him the basics and how to handle this approach in classic project management processes. It kept bothering me, so I researched for a combination of agile development and earned value management and found two very interesting articles.

The first one is by John Rusk – Earned Value for Agile Develpoment

The second is by Allistair Cockburn – Earned-value and burn charts

Both articles make assumptions and simplify evm, but anyway – these articles are great head start for the combination of agile development and evm. I will keep at it….

Read Full Post »

Today I want to tell you about a bet with a good friend. This friend is part of a software-project team, which was assembled by the upper management. The project is of prime importance and top management was in involved in the whole project acquisition process. The project did not really start till today, but all available resources, primarily top guns, where allocated to this project. They already got their roles and titles assigned, were seated on the same floor and got already their company-branded scrum planning poker cards.

So far so good…but let’s have a closer look… why do they need

  • a project leader
  • a project manager
  • a chef architect
  • a chef developer
  • a scrum master
  • a product owner
  • a test manager
  • a quality manager
  • a technology manager
  • senior developers and
  • management consultants?

This has nothing to do with project management neither agile nor classic. I think it is a common practice, to assign the best available people to an important project. Furthermore all project members get an appropriate title to signal their personal relevance. But who has the real project-responsibilty, who takes decisions inside this construct, what about personal vanities by collecting just alpha animals, what about the costs and who does the work finally?

For some IT Managers it could be very helpful to remember pieces of wisdom like “less is more” or “too many cooks spoil the broth” 😉

Btw, my bet was, that they will not meet their project targets regarding costs and schedule…and I will win the two crates of beer.

Image via Flickr: © by Greg Ryan http://www.Greggsgaff.com

Read Full Post »

Does Agile have lessons learned?

They are part of the process especially in Scrum. Scrum is about transparancy, inspection and adaption. At the end of each sprint there is a sprint review in which the product increment is demoed to all stakeholders and the product owner. The results of this inspection are reflected with the adaption of the product backlog. After the review the development team meets for a retrospective. This meeting is used to analyze: what went well, what went bad and how to improve it. This results in positive reinforcement for the good stuff and a list of action items for the next sprint for the bad stuff. Since a sprint is at max 30 days long you learn from your lessons at least once a month. Actually, the most common sprint length is 2 weeks these days.
Still 2 weeks is rather long to learn and improve. Therefore. Scrum has the daily standup meeting. The Scrum Master and dev team meet for a maximum of 15 min every day. In order to keep it short eveyone has to stand up, hence the name. Everyone has to answer 3 questions. What was I doing yesterday, what am I going to do today and are there any impediments blocking me. This is learning and knowledge sharing on a daily basis.

Scrum wasn’t designed with the PDCA (plan do check act) Deming circle in mind, but it is at the very core of it. As you can see, Scrum is about constant learning and improving. It fosters constructive communication. So, how about sharing lessons learned from one project to another. Scrum follows the agile manifesto and one of the rules is:

Working software over comprehensive documentation

Working software includes not only the end product but everything to build it. Agile automates about everything, so that the final end product can be build and deployed with the push of a button. Some call this executable documentation. In the case of the former post ‘Über den Sinn und Unsinn von Leasons Learned‘, you could take the executable documentation from a past project and have a real head start. You could hit the ground running and have real value from the get go. Sure, these are not fancy looking word documents but they are helpful. Not some kind of document which lost 80% of its original value by tipping it down and another 50% loss by reading it.
So in agile, within an project you have lessons learned on an ongoing basis. As for inter projects, you are welcome to take as much executable documentation as you see fit. Go and get this whole build pipeline and adapt as you learn.

The future is lean agile!

Read Full Post »

Gemäß dem PMBOK in der neusten Version 4 definieren sich Lessons Learned wie folgt:

“The learning gained from the process of performing the project. Lessons learned may be identified at any point.  Also considered a project record, to be included in the lessons learned knowledge base”.

Diese “Knowledge Base” stellt dann ein Archiv, mit historischen Projektinformationen dar. Bei jedem neuen Projekt stellt dies dann eine Unterstützung bei der Früherkennung von Problemen, bei der Methodenauswahl,… dar.

Soweit so gut. Betrachten wir das Ganze einmal in der Praxis. Gegeben sei ein klassisches IT-Projekt: Eine Server-Migration von Windows auf Linux. Dieses Projekt wird bei 10 unterschiedlichen Kunden von unterschiedlichen Mitarbeitern zu unterschiedlichen Zeitpunkten in verschiedenen Größenordnungen durchgeführt.

Wie erfolgt das Vorgehen in der Praxis nach meinen Erfahrungen?

Team A geht zu Kunde A und erledigt das Projekt besten Wissens, Team B marschiert zu Kunde B und erledigt das Projekt besten Wissens, usw. Im besten Fall beginnt  Team C sein Projekt erst nach Abschluss von Projekt A. In diesem Falle befragt (hoffentlich) der Projektleiter von C den Projektleiter von A, bzgl. seiner Erfahrungen. Der PL von Projekt A gibt seine subjektiven Erkenntnisse weiter und PL C startet mit seinem Projekt.

Sehen Sie das Problem? Wie kann ich sinnvoll auf objektive, bestehende Erfahrungen zurückgreifen, um nicht in die gleichen Fettnäpfchen zu treten bzw. um erfolgsversprechende Massnahmen umzusetzen?

Meiner Meinung können Lessons Learned hierfür eine Lösung darstellen. Sie sind besonders dann sehr hilfreich, wenn es sich um vergleichbar gelagerte Projekte handelt. Allerdings machen Lessons Learned Records nur dann Sinn, wenn folgende Punkte berücksichtigt werden:

  • Lessons Learned müssen eine unternehmensweite Methode sein. D.h. alle Projekte müssen diese Methodik verwenden. Dies muss auch vom Management unterstützt und vorgelebt werden.
  • Die Wichtigkeit von Lessons Learned müssen jedem Projektteam-Mitglied zu Beginn eines jeden Projektes klar gemacht werden
  • Zu Beginn eines jeden Projektes muss die bestehende Lessons Learned Knowledge Base nach vergleichbaren Projekten/Anforderungen durchsucht werden
  • Lessons Learned dürfen nicht nur Probleme, sondern müssen auch Erfolgskriterien enthalten.
  • Eine zentrale Speicherung der Lessons Learned Records muss möglich sein
  • Alle Lessons Learned Dokumente müssen allen zumindest Projektleitern zugänglich sein und via Volltextsuche durchsuchbar

Und wie steht es um die agile Welt? Wie wird dort unternehmensweit aus Vergangenem gelernt oder werden die selben Fehler immer wieder gemacht?

Read Full Post »

Older Posts »