Friday, October 30, 2009

Book: Mike Cohn - Agile Estimating and Planning

Everyone getting agile has to read this book!

Author: Mike Cohn
Title: Agile Estimating and Planning

Rating: highly recommended!

This book is just a must have and a must read! Mike Cohn describes all important aspects and concepts of estimating and planning in an agile approach. Lots of real-world examples show how to apply these concepts.

Note that this book is NOT about traditional estimating and planning for agile projects. It is about *agile estimating and planning* and this is what agile projects need to succeed.

You probably read several Scrum books and know the basics about story points, planning poker, story priorities, sprint planning, burndown charts, and velocity. If you really want to get in-depth details on all these and related topics you have to read this book! It is worth every single word - and Mike knows that "every word counts".

If you already are running agile practices then read this book and inspect your methods. You will find so many things to improve and adapt.

Enough said. Buy it, read it, and keep it on your table for reference!

PS: I'm looking forward to read Mike's new book "Succeeding with Agile". It will be on Amazon's stock on Monday.

Generalize Your Specialized Generalists

The software developers in a well-known Scrum team have undergone a transition from generalists to specialists in former times. They have been responsible for no specific parts of the software system. Every developer was assigned to the next high priority tasks regardless of knowledge and experience. Combined with classical waterfall project management, solo programming, missing code reviews, and missing unit testing, the resulting quality of the system was extremely low. There was a vast lack of knowledge of the old legacy code the team was working with. To compensate that knowledge all parts of the system were assigned to specific developers - a step that turned them from generalists to specialists.

Instead of moving out of the waterfall into Scrum and introducing pair programming and unit testing it was decided to go the pretended easy way and transforming generalists to specialists. Now single persons were assigned to specific parts of the system but unfortunately there still was a vast lack of knowledge of the old system. The major disadvantage of assigned specialists is the "not my job" syndrome: there always is another guy responsible for the task on my table so work can easily be pushed away. The next disadvantage is the "don't touch my baby" syndrome which instantly blames developers who dared to touch code not in their area of responsibility.

The team resulted in a hypoproductive group of developers, controlled by waterfall processes, solo programming, missing code reviews, missing unit testing, vast lack of knowledge, and individual code ownership: the worst of all worlds finally was born.

Productivity raised instantly after installing a working Scrum with that team. Bug rates dropped rapidly simply by applying the definition of done: code reviews and unit testing now are mandatory. As a next step single team members were asked to spread their knowledge via pair programming. This opened the way to collective code ownership.

The team has to improve a lot more and it will find out all those issues as impediments in the next retrospective meetings. Well, if they don't, the Scrum Master will give some hints by defining appropriate retrospective goals.

In the end, the team will become hyperproductive and will finally re-generelize their specialized generalists.

Tuesday, October 27, 2009

Drive-Driven Personality

There was heavy "agile fun" in the last months with all the agilists working close with me. We made lots of wordy jokes like "the goal is the goal", "the way is the way" which became things like "way-driven driving" and nonsense like that. Thinking of all these things all the time made me come to the conclusion of a quite meaningful term I'm going to explain: the Drive-Driven Personality.

"Say what? Drive-driven personality? Yup, right, c'mon, go away and never come back!"

No, really and seriously. It's that easy: Drive-Driven Personality is needed to push changing the world!

Many people just live their lives as is, be it private or professionally. These people may be good, valuable, hard-working thinkers with a quality above the average. Nevertheless these people keep things as they are most of the time. At max they optimize their local environment with smallest influence. But they never will change the world with what they do. They simply do not have the drive to force change.

Drive is not about power - most people do not have vast power to change things with a fingersnip. Usually power is given to people in a local scope only.

Drive is about an inner mental state - a heavy desire to do specific things. It's an inner calling, some kind of mission one has to complete with concentrated passion.

Typical examples of Drive-Driven Personality are writers, painters, artists in general.

Applied to Scrum: everything is quite simple and understandable in scrum. What for do we need Drive-Driven Personality? Jeff Sutherland explains the basic theory of bringing an average waterfall team to be hyperproductive - an initial kind of high-energy is needed to shake and trigger the waterfall team so that it is ready to start the journey. In my opinion this kind of high-energy has to be provided by Drive-Driven Personality. The ScrumMaster has to take care that not only the team but the surrounding organization is ready to start the journey into agility. If you do not possess inner drive to change anything, your attempt to do so will stagnate after a while and will end in keeping a status quo. A Drive-Driven Personality is needed or risk to fail increases.

What for do we need Drive-Driven Personality if our scrum team already moved to a score of 6.4 on the Nokia scale? The team is self-organized, holds retrospectives, and understands how to improve on a regular basis. In this case you need a Drive-Driven ScrumMaster to perform the last hard step bringing the team hyperproductive to a score of 10. There will be impediments to change or remove which are way outside the scope of a scrum team. To change old top-management structures a fearless, Drive-Driven Personality is necessarily needed.

Drive-Driven Personality is what you want for everyone you are working with! Whenever you have to recruit and get people on your team, find out if an applicant is Drive-Driven enough for her job. Avoid working with mediocre skilled people - search a Drive-Driven team and your working paradise is reached.

Monday, October 26, 2009

Book: Mike Cohn - User Stories Applied

Everyone getting agile has to read this book!

Author: Mike Cohn
Title: User Stories Applied for Agile Software Development
http://bit.ly/POrak

Rating: highly recommended!

During any approach to implement agile procedures in an organisation there is a need to explain how management and engineering of requirements should work. Coming from traditional waterfall projects most people do not understand what those User Story stuff is all about. Usually lot of concerns are mentioned...

"So, User Stories are Use Cases, right? Why don't you just call it Use Case?"

"But we need all requirements at the start of our project. How should that work with User Stories?"

"No, we don't need that. We know what the customers want and we know all features of the product. What for should we waste time with User Stories?"

Mike Cohn is one of the most experienced agilists and board member of the Scrum Alliance. In his book he explains every detail you must know about User Stories. This books makes you understand how to argue against the usual concerns. Mike wrote down his vast experience and makes any aspect of the topic easy to read.

Did you ever wonder how to deal with nonfunctional requirements in Scrum? Read this book and find out.

Did you ever ask who would be the best product owner writing your stories? Read this book.

Have you read this book and still have issues bothering you about User Stories? Well, you either got lost in something else than being agile or you probably may be on to something really new.



Thursday, October 22, 2009

Guerilla Scrum: How to force organisational change

Situation

Many organizations do not dare to change themselves although everyone knows that things do not work well. Usually real working employees have a good feeling that things are going wrong. Unfortunately they do not have the power to trigger change but expect middle management to do so. Usually top management expects everyone to do the best job and will ask questions to middle management if things go wrong. Therefor middle management is sandwiched with expectations - this is a hard job to handle and needs explicit skills.

People tend to keep an organisational status quo for several reasons:
  • Why change anything? Never change a running system.
  • A change would have impact on many parts of the organisation, we just can't do this.
  • We do not have time for changes.
  • We do not have budget for changes.
  • We can't change anything due to laws and external regulations.
  • We already tried to change things but it didn't work.
  • My boss forbids change.
  • I do not change anything so that I am not responsible for any fault.
Analysing any single reason not to change an organisation leads to the basic cause: fear-driven management avoids organisational change.


Solution

Four phases as follows are needed to overcome fear-driven management and force organisational change.

1. Guerilla Scrum

Guerilla Scrum is about just starting to change things in your own local scope of influence. Simply start your next project by applying scrum. Even if you have to deal with scrumbuts like missing product owners or an unprepared team you should start scrumming. Try to live scrum with all the few details it prescribes. Just do it and the results will prove your right decision.

If you can't setup a scrum team or if you are bound to a running project, then try to apply as many of the following:
  • Inspect and Adapt: setup timeboxes of several weeks in your project and bring together all team members on a regular basis to do retrospectives of these timeboxes. Do this to find obstacles and impediments and remove them as soon as possible.
  • Direct Contact: bring people together. Make people communicate with each other. In many projects people talk to the project manager only instead of talking with the co-worker in the neighbour room. Force them to work in direct contact.
  • Show Progress: use the mentioned timeboxes and give a project presentation at the end of such a box. Make the team responsible to demonstrate what they have achieved. Try to invite your product manager or whoever is the major project stakeholder from the business point of view. Convincing this business guy is important for the next point.
  • On-site Customer: bring in the convinced product manager to talk to the team. Use this direct contact to clear requirements and get a better understanding of each other.
You will see huge overall improvements after repeating these things two or three times.


2. Push into Organisation

Visit the barber, jump into your best suit and get ready for marketing: make your improvements visible to other parts of the organisation.

Do not promise the silver bullet! Do not promise infinite ROI and do not promise vast improvements by presenting the theory of a new method!

Simply present the real, measurable improvements of your guerilla scrum. Just mention a few words about "agility" and "scrum", just give an indication of doing things differently than before.

You should explain some details of your scrum to the next neighboured managers: show them the daily micromanagement, the tracking of all things, the planning, everything - and let them be both surprised and confused. They will need time to think about what they saw.


3. Expect Growing Interest

The word will spread through your organisation: the product manager will talk to her colleages, your manager will mention improvements of his department with a new method. Other people will take notice of you and your team.

Members and managers of other departments probably will contact you to learn more. Use this chance to give a presentation on agile methods. Set a date for a workshop on timeboxing, agile estimating, or any other interesting agile topic.

Don't forget: always include step 2. and continuosly present your real improvements!

Persuade as many stakeholders as possible.



4. Use Multiplicators

Time will come when someone will have entered the agile train. Maybe another project manager read a book, joined a conference, or actively went into agile in any other way. There will be people getting the big picture and have their eyes opened.

Use these people, they are your allies! Let them spread the word for you. Support them and get supported in return.

Ideally some of these people are from top management - these are your wanted multiplicators! Try to sandwich your middle management organisation with agilists: persuated managers and successful, improving project teams.

When enough people are on your side, being agile becomes common sense and will not be questioned any longer.


Conclusion

Every organization is able to achieve major improvements. Overcome fear-driven management by proving results of guerilla scrum. Do marketing and present your real improvements and results. Persuade as many people as you can, so that being agile becomes common sense.

The most import agile principle of "Inspect and Adapt" will help your organisation to embrace change - so finally you reached your goal.

Friday, October 16, 2009

Personal Taskboard: Evolution to Mobile




The major disadvantage of a wall-based personal taskboard is its pure static character. You can't take it with you for travelling or for working on it at home.

Here's the solution: the mobile personal taskboard.




Side note: this version of the personal taskboard is not used by myself but I like the idea a lot. For me it works to move the 2 most important task from my wall-based board into my paper book. So my paper book is some kind of additional optional external kanban lane.

Don't forget: always inspect and adapt! This topic will go on for sure...

Personal Taskboard: Evolution to Priorities



Just a small update on my personal task board: as the open tasks got more and more it was hard to filter and select the next task to pull into WIP (work in progress).

Solution: tasks are now sorted by urgency from left to right and by importance from bottom to top. The most upper right task is ready-ready to jump into WIP.

To be continued...