Saturday, September 26, 2009

Personal Taskboard: Evolution to Kanban

A few weeks ago I setup a personal taskboard at the wall next to my desk. It had three lanes like a Scrum task board: "open", "in progress", and "done". After one day there were lots of things in progress and two tasks were done already:



The major problem was the number of tasks in progress. There were just too many things ongoing so that control could easily get lost. Fortunately things were sorted out a few days later. Lots of things done and few things in progress:



After a while I recognized the repeating problem of too many thing in progress. After a short personal retrospective I decided to improve my focus on the "in progress" lane. It seemed obvious to limit the number of things to work on in parallel. I splitted the "in progress" lane in two parts:
a) an "on hold / wait" part for all the things that have been started but need external help
b) a "working on" part with focus on all the things in progress. This part now is a Kanban box with a limit of two tasks.


The positive effects of this change appeared instantly: things got their focus on the essence! Tasks were done in a much more sustaining pace than before.

I am curious about the next improvements of my personal task board. Let's see what my next retrospectives will expose.

Wednesday, September 23, 2009

Sprint Meetings in Distributed Scrum

My current scrum team is distributed in three locations:
  • Location A: developers only
  • Location B: testers and the product owner
  • Location C: testers, developers, and the scrum master
In this situation we have to deal with some lack of communication. Location A is in a different time zone, 5 hours away, which makes communication even more complicated. We can't use a simple task board everyone can easily work with on a daily basis. Electronic documents are used to substitute most sprint artifacts.

How do we succeed with all those sprint meetings we have to perform? Daily scrums, sprint review, product demonstration, sprint retrospective, sprint planning. These are quite hard to do with emails and phone calls only. In fact it simply is not possible to let the team improve by these means. (And please do not call it Scrum if you have to work that way.)

We use a video conferencing system to connect all three locations in all the meetings necessary. The team sits together in virtually one room, can see the other team members, and has direct communication with everyone. This is just great and after a few seconds you simply forget that the other people are far away.

To simulate the feeling of everyone standing in front of a task board, we use a remote desktop system with one master and two client connections. That way all participants are able to move the mouse, enter some information, and instantly see what other people do with the documents.

Today we had a really good distributed product demonstration for our product owner. The software system was hosted at location C, was presented by a developer of location A for our product owner sitting in location B. The product owner was impressed of the early feedback. As our testers already have done their job, the software was in a really good quality. So the product owner said something about "wonderfull" several times, which made the team proud of what they had achieved in the last two weeks. The product owner also gave suggestions and hints (in traditional tongue: "detailled requirements") so that the developers understood way more than a written requirement specification document ever could provide. I just love these short feedback cycles, the increasing team motivation, and the positive outcomes of Scrum!

Hint of the day: get video conferencing systems and remote desktop systems if you have to deal with distributed scrum meetings!

Friday, September 18, 2009

Plan-Driven Testing fails with Agile Developers

There were two situations today in the office that opened my eyes. I finally understand why it is so hard to form a team of plan-driven testers and agile developers.

Our daily scrum meeting went fine today. Our iteration progress is back in parallel with the ideal burndown after a 2 days upward drift.

After the meeting a tester came to me and said, "it's really annoying to notice in the daily scrum that some stories are ready for testing. Why don't the developers write me an email?"
SM: "What's your problem? You just got the information a few minutes ago in the meeting. What could we improve to help you?"
Tester: "I don't know. I just don't like to wait for answers. The developers do not react on my postings in the bug tracking system. Therefore the testing crew is in waiting mode."
SM: "Have you asked the developers?"
Tester: "What do you mean?"
SM: "Whom did you give a phone call? Did you talk to a developer directly?"
Tester: "No, they know that they have to write me an email."
SM: "OK, obviously we have to improve something here."

I stopped the discussion. And I am very curious if this issue will be mentioned by the tester in the next retrospective.

Later in the afternoon I went to the test lab. I met another tester there and asked, "Have you seen all the fixed bugs in the bug tracking system? There's lots of stuff ready for testing."
Tester: "Oh, no I didn't take a look."
SM: "You could start to look right now."
Tester: "'Err, no first I need the bug list."
SM: "What do you mean? Just take a look at the bug tracking system to get that list."
Tester: "No, one of the other testers is responsible to create an Excel sheet with the bug list. Then we can coordinate who is testing which bug when and how long."
SM: "Yeah, OK, I understand."

I stopped again. And this time I was sure that this issue will be mentioned in the next retrospective: testing has to be agilized much more!

Imagine to have a detailed iteration task board which gets updated every morning in the daily scrum by the whole team. Everyone knows, what's going on, and everyone is up-to-date. But simply having actual knowledge of status is not enough for the testers - they want to be informed explicitely by email. Then one of the testers takes a look at the stories "ready for testing" and maybe takes a look at the bug tracking system. The bug tracking system is already one redundant system too much but for the testers even this is not enough. One tester copies all important information out of this system into a new list. For what sake? Simply to fall back to old habits and have a plannable list of things one can assign people to and give each an effort estimation.

If the next retrospective meeting would not be within the next 3 days, I for sure had raised my voice today. But I'm sure the team will see and mention these issues on its own. The next retrospective will be exciting!

Tuesday, September 15, 2009

Transition of the Definition of Done in Regulated Environments

Projects in regulated environments have to follow strict guidelines and rules. Laws, normative regulations, product risk analysis, and detailled development processes are defined and controlled by Quality Management departments. Besides of that you have to deal with external groups like editorial staff for documentation.

From a User Story's point of view all of the following is necessary for a proper Definition of Done:
  • Done: internal Scrum DoD (specified, implemented, unit tested, reviewed, UI tested, integrated, and so on)
  • Done-Done: external Documentation DoD (readme edited, online help edited, user manual edited, translated, layouted, printed)
  • Done-Done-Done: external System Release Testing DoD (regression tested, all stories tested, documentation tested, system interoperability tested, etc.)
  • Done-Done-Done-Done: external Quality Management DoD (risks analyzed, overall risks reviewed, remedial actions defined, project documented, and much more)
One could argue to change the organization to move the external departments into the agile team. Not only laws and regulations make this impossible but there are simple economic and time issues as well:
  • Documentation can't be translated on a User Story basis every time something changes. This would get too expensive and it is much easier for an external translator if she has the final document ready at hand. Nevertheless a translation into a dozen languages may take up to 4 weeks.
  • System Release Testing can't be started until everything is finished and shippable. Unfortunately some unexpected behavior on a User Story basis may be reported which need instant action (code adaptation, re-documentation, re-review, re-testing).
  • Quality Management departments traditionally follow a very waterfalling approach. After every other thing has beed finished they start to look at a project, do some reviews, read project documentation, and - worst of all - start asking questions and suggesting changes here and there. These changes may have impact on single User Stories.
So how do we deal with all these "Dones"?

We have to de-agile our project and split it into phases:
  1. Development: here we do Scrum at its best - but we are never able to ship our product after any sprint
  2. Documentation: all documents will be finished, translated and ready to be shipped
  3. System Release Testing: the shippable product will be tested from scratch
  4. Quality Management: all documentation and project results will be reviewed and the final "Go" is expected
Next, we move as many DoD parts as possible from the later phases to development:
  • "documentation drafted" from Documentation to Development: sketch the documentation changes for every single User Story. I recommend to find a semi-team member in the documentation department and deliver all drafts after each sprint to her for a first review.
  • "risk analyzed" from Quality Management to Development: think about product risks of every single User Story. Again I recommend  to closely work with a QM guy after each sprint.
  • In general "any small thing finished" from later phases to Development
With this approach we are able to strengthen the DoD we are tracking in our Daily Scrums. We move as many tasks as possible to the early development phase and thus we handle risky things right from the start.

The big advantage of more early "Dones" is the expansion of the agile, iterative development phase. Agile progress tracking can unfold its power with much more tasks being finished during development. As a result all later phases have less risk of failure.

Monday, September 14, 2009

Explaining Agile Projects

Here are some impressions of expressionistic drawings while I explained how we do Agile Projects to some people.


The complete picture



This drawing covers a lot of aspects. Try to find as many as possible:
  • Definition of Done
  • Iterative cycle of system qualification (testing) and bug fixing (development)
  • The need to release multiple software products due to shared components
  • V-Model (with a substitution of level "P"roduct with "F"eature)
  • 50% buffers
  • Parkinson's Law
  • Feature Branching Strategy


Single Point of Communication



In organizations without fully implemented Scrum teams there always are victims in the center of all other groups. The poor guys in the middle (old fashioned project managers) are flooded with questions from the developers and testers (left) and instantly have to pull answers from the business guys (right). As a result, they constantly jump from left to right and vice versa.


Agile Process Refinement


This image shows an approach to implement mixed agile processes to an organization:
  • Discuss about features on an epic level with top management. Call this FDD for these guys and show them the FDD process - they do not need more details.
  • Refine these epic features and create detail feature specifications with the lower management and business people. I call this F++ just for fun. They want to discuss implementation details and user interfaces - in fact, this is where user stories are created.
  • Implement Scrum (or better: ScrumBut) for the development and testing team, use task boards, burndowns, dailies, and retrospectives.
  • Major goal in this drawing: pull the business guys into the Scrum team and convert them into real product owners.

Sunday, September 13, 2009

Book: Esther Derby, Diana Larsen - Agile Retrospectives

Everyone working with teams has to read this book!

Authors: Esther Derby, Diana Larsen
Title: Agile Retrospectives - Making Good Teams Great
http://bit.ly/cvoaH

Rating: highly recommended!

Esther Derby and Diana Larsen describe 38 activities for all stages of a retrospective meeting. These activities provide ways to improve the team work and to get better results of the retrospective. There are no rules when to choose which activity but you get a nice set of activities to select from. Goal: avoid boring routine by varying activities.

Retrospectives are one of the major keys to successful agile teams! This book helps to improve teams and so to improve the agile approach of a team.

Be aware of technical teams being focussed on hard skills rather than soft skills - this may be a problem to solve before introducing an activity working with feelings of team members and the expression of feelings. Tech staff often judges such things as psycho stuff. So what is the great thing about retrospectives? Even the 'psycho stuff' situations will improve as the team does.

Conclusion: read this book and try to vary your very next retrospective meeting.

Friday, September 4, 2009

ScrumBut: The "Agile" Buzzwords

A normal day in the office. I tried to get more details for some stories from a product owner. Half an hour before lunch time a co-worker entered the room, we did some small talk and made an appointment to go for a walk'n'talk later.

Suddenly he wondered about the book on my desk: "Agile Retrospectives" by Esther Derby and Diana Larsen (http://bit.ly/cvoaH). He took a look at the back and read "Project retrospectives help your teams examine what went right--and what went wrong--on a project."

He instantly asked "Why is any new book called 'agile'? There are enough 'agile' books on the market. Is there any need for a book on retrospectives? Doing retrospectives is a common project management method, so what for do we need that 'agile' buzzword for retrospectives?"

In my point of view we need the 'agile' buzzword for everything we do! Why? Simply to intensify our agile project marketing. There are lots of stakeholders who still do not understand what it means being agile. We have to throw all that agile mumbo-jumbo around so that they get the chance to ask what we are talking about.

"We have to get higher quality, faster development, more features realized, so we will use a bunch of agile best practices. But whatever we are going to do, the most important thing is to control everything in a closed-meshed manner. And we need key performance figures."

The biggest ScrumBut in this quote is "use a bunch of agile best practices": do some planning poker here, take the name 'feature' from FDD, talk about Critical Chain project management, and write a 40 pages definition of those 'best practices'. Will such an approach have any chance for success? I doubt it.

Lets take a look at the other points of the quote. You want to control everything? Of course, you can, it's no problem at all: daily scrums, iteration reviews, and product demonstrations will assure controlling. You want figures? Just collect our agile metrics and you have them: velocity, burndowns, number of stories done, and so on. But what is the goal of controlling and collecting figures? We want to improve our team, our methods, our agility. The best way to improve is by implementing retrospectives the agile way (just read the book on my desk if you want to know more http://bit.ly/cvoaH).

Once a manager said: "Could you please stop talking about 'timeboxing'! This concept is so old and it's common sense to keep track of my project at least once a week. I don't want to hear that term 'timeboxing' any longer!"

"Timeboxing is not about frequent progress tracking, it's about fixed lengths of meetings and iterations. You even can timebox our release if we have to be date-driven. If story priorities change at the end of the timebox, some lower valued stories will just be moved into the next release", I replied.

"What do you mean 'moved into the next release'? You gave the promise to implement this set of features for this release at the planned date."

"You know reality. Project scopes change constantly, things may be decided to be more important this month and less important next month. Additional features are moved into a project and some other features get too large to be implemented at the proposed date. If your goal is to release twice a year, we have to timebox our releases to 6 months. This will guarantee a sustainable pace for the releases. If additional requirements get into a release, some other stories have to move to a later release. Otherwise we will not be able to guarantee a new release of the product every 6 months. Even worse: the succeeding release will be delayed before it ever started."

Somehow my last sentences opened his eyes at least a little. But that ScrumBut discussion has not been finished yet. I will report the results of our next discussions, of course.

The team leader of a group of developers once said: "we will not do iterations. That would be too many changes for the team, let's just do this feature driven-development now. If this works, maybe we can do some more."

This one is a heavy ScrumBut: do half of some agile method. Without iterations every other advantage of being agile gets lost completely. You would win nothing if you had to take a look at the project's results half a year later for the first time. Iterative planning and iterative retrospectives are so important that they must not be skipped by any means!


If you want to know more about ScrumButs, take a look at Ken Schwaber's site http://www.controlchaos.com/. Some interesting thoughts about ScrumButs can be found in http://www.noop.nl/2009/09/scrumbuts-are-the-best-part-of-scrum.html.

Tuesday, September 1, 2009

Daily Tracking

A big advantage of the perfect world of strong, deterministic, complete, overwhelming and unchangable project scopes is that you can track your progress on a micro percent basis, two post commas included. All glory to the waters falling from beginning to end!

Suddenly everything is different in the real world where we live such wondrous things like Scrum.

I was asked by a senior project reviewer how I do track the progress of my projects. He was wondering about missing work breakdown structures with assigned resources and working hour efforts - none of that was in my pro forma MS Project plan.

I told him about story point estimated, feature story based release planning and burndowns. "OK, but..."

I told him about iteration planning, task breakdowns of stories, task estimates in hours, daily scrums, daily progress, daily tracking, daily burndowns, daily knowing-what-happened-what-will-happen-and-what-the-issues-are. His eyes got wide and he said "wow, I'm really impressed of such direct, short-term feedback cycles. Let's give it a try. I'm curious about the results of the next weeks."

Satisfied we left the meeting and yet another time I thought how easily critical people get persuated simply by explaining the details of what we're doing on a daily basis.

Praise the Daily Day!