I recorded a small webcast to visualize the difference between multitasking and a 100% commitment and how this can lead to functional releases - essentially to being agile!
There is one element in Scrum which I really appreciate. It is the separation of power in Scrum.
What exactly do I mean with this? Democracies are based on the separation of powers they require.
Legislative
Executive
Judicative
Each one has their rights and responsibilities. The other two watch out and make sure, that third doesn’t abuse it’s power.
In totalitarian governments this is not given. One entity reigns over all three. The usual result is that a few benefit and many suffer - from individuals to whole economies.
What does this have to do with Scrum. Well, nothing - at least at a first glance. But if we apply this concept to classical management, the project manager has the possibility to act as a dictator.
He or she can decide about all three elements: scope, schedule, people.
The image above is the incomplete ‘iron triangle of quality’. It tells us, you can choose two out of the three, the third has to give. For example, if we have a certain amount of scope to implement by a given date, we need to adjust the number of people working on it.
If all three are set then the quality of the product under development will be sacrified when things get tough. Quality is the forth hidden element. Often the manager tries to convince us about the attainability of the goal with sentences like ‘I know it is aggressive but …. ‘, ‘You are not a team player ….’ and more.
Quality dies first on every software project. It is not transparent per se, it won’t show until very late in the project or even until the product has been released. This manifests in very high TCO (total cost ownership). Eventually the developers require to rewrite the piece of sh.. garbage software. (see my blog Resetting the Shitty Counter)
How is this handled with Scrum? In Scrum the Definition of Done (DoD) states certain attributes or activities which have to be present in order to guarantee a high quality, potentially releasable product. The compliance of the DoD is paramount to a high quality product with happy customers and low TOC. Now Scrum is not immune to crunch times, times when the Product Owner (PO) is tempted to push the Development Team a little further. In those situations it would be just to easy to abandon the DoD and reduce quality to keep the date and make the Product Owner happy.
This is when the Scrum Master comes in. She will make sure that the DoD stays enforced and keeps the PO at bay. Essentially she protects the people (Development Team) so that they can work in the agreed way and thereby create a high quality product.
In Scrum the Product Owner has the right to decide which feature gets developed in which order. His tool for that is the Product Backlog.
and the Scrum Master ensures that the Delelopment Team has the right to estimate the work according to the Definition of Done and to implement it according to the Definition of Done.
The separation of power protects the Development Team and allows it to deliver high quality product increments throughout the project. This sustainable approach guarantees high quality software with high ROI, low TCO -- easy to maintain, easy to support, easy to enhance -- for a long time. Best, you should see happy, engaged developers.
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. […]
Billy (below) is a known old bug. Old enough that it got a name and is well known to the development team.
Bugs, or defects in your software, are not to be treated as pets! Make sure you close bugs fast. Do not get used to bugs.
Agile software development (as typically is the case in the software industry) does create bugs. In fact I came across new Agilists that were surprised because Agile development practices also create bugs; in fact, I have seen more bugs (I am not talking about defects in production) in Agile development than in more traditional development.
But what I expect from a well-working Agile team is that:
The number of bugs in production is low
Bugs are closed very fast
Test Early and Often
Agile development practices such as continuous integration, test driven development, and automation facilitate the quick detection and elimination of bugs. Your customer tests (test validating the customer requirements) will detect any addition or change that breaks an existing test. Your developer tests (tests validating the design of your application) will detect anything that breaks the expected design and behavior of the application.
Disclaimer: for smaller teams, this will be as simple as identify and fix the recognized problem. But for very large teams, it might get a little more elaborated, and a bug is created to track the issue (at times, the issue itself is that there was no automated test).
Scaling Agile
Scaling Agile has a few nuances to it. And bug management and resolution is amongst the development practices that require special attention for a large Agile team. From my experience on a large Agile program, I second the importance to classify bugs by priority and severity.
But even with good bug classification and management, I noticed a few old (pet) bugs living in my large Agile program.
Consider the program had an average rate of 100 new bugs per week. Don’t be alarmed, it is a huge program. Imagine 100 developers continuously integrating code for 200 user stories per week. And an average rate of closing 100 bugs per week.
The depicted scenario can be of a very healthy Agile program. For instance, a small period of regression ensures the production readiness for the system. As Regression I mean the period allocated to stabilizing--fixing the bugs-- the next releasable artifact; not adding new features.
But how is this sample program creating old pet bugs?
Low priority, low severity bugs. These are the bugs that can live a long life.
If the reasoning for deciding the order to attack the bugs only considers severity and priority, you might be creating pet bugs. I did recognize a few elder pet bugs (for this reason) in my large agile program.
My recommendation is to adjust your bug triage formula. You should consider severity, priority, and the age of the bug.
I am sorry Billy (my old pet bug). Even though you were low priority and low severity, it is being embarrassing to have your small –almost inoffensive—existence in the system. I am sorry, but you have to go!
Posts
