Feeds:
Posts
Comments

Archive for the ‘SCRUM’ Category

In ancient times, it was not uncommon to kill the bearer of bad news. It was a matter of principle. “Don’t bring me bad news. And by the way, don’t fail with your efforts.” Luckily, in these days, the worst that could happen to you is to be fired – not much better in the current economy but, hey, who complains. However, still too many projects or companies are run in exactly that very way.

How does this fit together with Scrum? Not at all! Scrum is built on three legs. Transparency, Inspection and Adaption. It is the Transparency part which is in conflict by not being able to tell the truth, the naked truth. All software projects will encounter problems and are predictable only within a short planning horizon. Most non-trivial software projects belong to the complex category according to the Cynefin framework. Complex projects cannot be managed by a defined approach but require an empirical process. It is the empirical approach that is based on Transparency, Inspection and Adaption. Empiricism wants feedback; this is why Scrum has Sprints, Daily Scrum, Review and Retrospective. They are the empirical process controls. They provide feedback about the product under development, the progress and the process. All of them are subject to change when appropriate. Inspect and Adapt!

Now, imagine a company which is run top down military style. You get your orders, don’t dare to even question them and then report back. Your reports are checked against the minutiae defined plan, often a Gantt chart. You cross your fingers that you will not be the first one to bring down the plan. You know what happens to the bearer of bad news! This is a very toxic environment for any kind of agile change effort. The moment you discover or run into some serious situations people tend to loose their ability to speak up. The situation becomes a problem and looses its opportunity for improvement. Forget all about Adaption and improvement. In short, the whole effort is futile.

A successful Scrum introduction needs an open management. A management that can let go of being in control and is able to change from

Command and Control to Leadership and Collaboration

This is the most challenging part for management. Essentially they need to make themselves obsolete and become servant leaders to their teams [1]. Until this happens, it is my job as external Scrum Coach and Change Agent to shield the teams I am working with. At the beginning of a Scrum introduction, it is much easier for the teams and the management if I – as the Coach – am the one stepping up, telling how things really are and even taking the fall out. It is not always fun but it is very rewarding as it builds up the trust between the Scrum Team and myself. The individuals on the client might risk their careers; but myself, in the worst case, I only get shown the door. I am a paid sacrificial lamb.

I am a European who has worked in Germany, France, England, USA and now Switzerland all along my career and based on my experience, I am sorry to admit that there is something about the term ‘Old Europe’. In continental Europe, there seems to be a lot of rigid top down hierarchies, still. Maybe this is the reason why the agile adoption takes longer to get going over here. However, I am happy to see dramatic changes this very past year.

Give me a call if I could be of help to you or your company.

[1] Dan Pink, Drive, Kindle Location 1275, […] Autonomy over task has long been critical to their ability to create. And good leaders (as opposed to competent ‘managers’) understand this in their bones. […]

The future is Lean-Agile

Read Full Post »

Eigentlich wollte ich diesmal wieder auf englisch schreiben, aber nachdem wir auf den letzten deutschen Post die weitaus besseren Zugriffszahlen hatten, versuchen wir es nochmals so. Ich hab in letzter Zeit viel in anderen PM-Blogs gelesen und dabei wirklich viele interessante Ideen und Ansätze aufgeschnappt. Besonders die Themen Selbstorganisation, Organisationsformen der Zukunft und die Kombinationsmöglichkeiten von agilen und klassischen Projektmanagement-Methoden werden immer wieder kontrovers diskutiert. Hervorheben möchte ich hier u.a. die Blogs von Stefan Hagen und Jurgen Appelo, sowie die gesamten YouTube-Videos von Prof. Peter Krause. Aber jetzt kommt mein großes ABER bzw. meine Frage:

Wie setze ich das Alles in die Realität um?

Wer beschäftigt sich mit diesen Themen? Firmenchefs und Manager? Ich denke, dass dies nur in wenigen, seltenen Glücksfällen die Realität widerspiegelt. Gehen wir doch einmal davon aus, uns weder in einem super-dynamischen web 2.0 IT-Unternehmen zu befinden, noch mit einem Management konfrontiert zu sein, welches nicht an den guten, altbewährten Methoden festhalten will. Wie argumentieren wir? Wie überzeugen wir einen Patriarchen eines mittelständischen Unternehmens davon, nicht mehr der Alleinherrscher zu sein? Wie überzeugen wir Ihn davon die Transparenz in seinem Unternehmen zu erhöhen und hierarchische Strukturen abzubauen? Wie bringen wir ein Management dazu diese “radikalen” Methoden umzusetzen und sich – in Ihren Augen – damit gleichzeitig selbst zu schwächen?

Als ich auf meinem damaligen PMI-Vorbereitungskurs war, fragte mich der Trainer, ob meine Chefs auch schon diese Zertifizierung haben. Auf meine Frage des warum’s, antwortete er, dass ganzheitliches PM nur funktionieren kann, wenn das gesamte Unternehmen dahinter steht – mit allen Konsequenzen. Wie wahr. Aber dieses Bewusstsein auch an den richtigen Stellen zu schaffen halte ich für äußerst schwierig, weil dies oft Verzicht bzw. radikales Umdenken erfodert. Über zahlreiche Meinungen zu diesem – meiner Meinung nach – sehr diffizilen Thema wäre ich sehr dankbar.

Read Full Post »

Don’t know what your experience is like, but for me it is the following. Meetings are much more productive when someone is standing at a white board and writes down ideas, risks, problems and what have you. I am sure every single human being who has attended enough meetings has observed the default pattern — or anti pattern — in meetings. Everyone has their point of view and does all necessary arguing to protect their idea. They fight each other instead of pulling together towards a common goal. Often after a long and useless meeting it is commonly decided (the only agreement) that another meeting is needed.

One way to counter this behavioral pattern is to mail out an agenda with all the topics and asking the participants to prepare. This might help but most often it does not. I even doubt that every recipient of the mail does read it entirely. It usually drowns in the sea of more important emails.

Now, imagine you are in a pissing contest meeting and someone gets up and starts to write the different points clearly visible down. In a heart beat the whole meeting has structure, everyone turns their head towards the board. Not the loudest voice is heard but all ideas. Often, after some time the whole group is working together towards a — just identified — common goal. If you don’t believe it, then give it a try at the next deadlocked meeting. You will be amazed how much power a white board and a marker in hand can create.

Why am I writing this? Well, Scrum has this at the core of all of it’s meetings. In Scrum we have four different meeting types. Sprint Planning meeting, Daily Scrum, Review and Retrospective. Usually each of those meetings is moderated by the Scrum Master. It might be moderated by someone else but it is always moderated! The medium to write on are either index cards or PostIts which are aranged on a white- or corkboard. Those cards are then updated and rearranged during the course of the sprint. A very visual way of management. Alistair Cockburn named it accordingly: Information Radiators.

Next time your are stuck in a non productive meeting just get up and start to use a marker and whiteboard. Everyone in the rooom will be grateful.

The future is Lean Agile.

PS If you are interested in a simple way to moderate a meeting then try out Edward de Bono’s Six Thinking Hats

Read Full Post »

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 »

Older Posts »