This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Wednesday, April 23, 2008

Communication is really hard! No, seriously!

So, we knew already that communication is hard. Nothing new there, but here's a few insights into why, the so called
Wiio's laws.

Remember the discussion about why we should no rely on documentation to share information? How about this law:
  1. Communication usually fails, except by accident
Sobering observation! Now, wouldn't you wish you had talked to that developer yesterday instead of sending him that e-mail? You would have avoided a lot of problems today, wouldn't you?

Labels: , ,

at 19:34 | 0 comments links to this post
RSS link

Bookmark and Share

Tuesday, April 22, 2008

An inconvenient truth, in work management

I bet anyone in my position (Agile Coach) has faced this before: you present a work method to a team or a person (be it scrum, XP, DSDM, FDD, etc.) and they go "yeah, I see what you mean, but that would never work here".

If I only had a dime for every time I heard that I could be rich!

Today it happen again. Here I am presenting the
Personal Scrum work method. People are following, they are asking some good questions and at some point it hits: "Yeah, I see what you mean and it makes sense, but that would never work for us. We have too much work we cannot predict because we want to have a very fast turnaround for our customers (1 business day) and that's why we cannot really plan our weeks that way. On top of it we are too busy to spend that much time (1-2 hours/week) planning what to do."

Now, for most of you (if not all) the problems in this phrase/quote are quite transparent, but for the person saying it, it was not. They did not understand some of the basic principles of work/time management and productivity:
  1. If you cannot allocate your whole week because some portion of it will be "unpredictable" (have you heard of maintenance in production software?) then you don't allocate the full week to planned work! That's not a reason not to plan... Just estimate how much time you need for "unexpected" items (and that tends to be pretty regular from week to week), and plan the rest of the time!
  2. If you are too busy, then how do you know your are doing the most important things for your stakeholders/customers? Are you setting aside the time to think through the priorities of your work from your customer/stakeholder's perspective? If not then I'm sure they'll be mad at you or at least disappointed -- even if you are busy!
  3. If you are too busy (yes, again), that means you are "thrashing". This means: you have started many threads of work but are getting none of it done! Remember that only work that is "done" counts. Starting something you don't finish does not count (unless your manager/supervisor is clueless, in which case it is time to search for a new job anyway). Search for the ZEN of getting things to "done".
  4. Work is work. Stating that a method (whatever that method is, take GTD for example) does not apply to manage your work can only be a result of not understanding the basic essence of any piece of work: 1) you get an order with some information and possibly inputs; 2) then you process it, alone or with a team; 3) finally you finish the work (as in "done"). This is true for every piece of work that needs to get done, whether it is planting potatoes or designing a piece of software, and certainly writing a business proposal or answering an RFP. If you don't understand that basic attribute of work there's a deeper problem we need to address. Managing the work is the least of my worries when I face this type of situation.
Now, all of these observations could have been done by anyone with experience in trying to manage work. But (and this is the sad fact) there's not too many people out there that understand the concept of "managing one's (or one's team) work". Sigh...
This brings back memories of a conversation I had with a senior and well known Scrum trainer/guru when he was training at our company:
In the CSM training, after the "promise" game exercise he was looking down and gloomy. I walked up to him and asked what was the matter. He turned and said: "see, this (the problems uncovered by the "promise" game) is what I see in all companies I visit, and that just makes me feel sad about the state of our industry. See, what I'm trying to do is just make our industry better, more professional".

Indeed, better and more professional. That's the right goal!

Labels: , , , , , , , ,

at 22:13 | 0 comments links to this post
RSS link

Bookmark and Share

Personal Scrum, 2006

So Personal Scrum is not that new.

That does not surprise me as it seems to be such a good process for managing any work that, in my view, approaches a basic Pattern in work/tasks/time management.

Great article.

at 21:28 | 0 comments links to this post
RSS link

Bookmark and Share

Monday, April 21, 2008

Respect for people, the translator's edition

In the spirit of Lean my colleague and friend
Mika Pehkonen writes how they are able to respect people, get them to do what they are best at and most motived to do. I'd say that's a win-win-win situation!

we pay our translators by the hour, not by word count. This means that the translator gets fair pay for their work, they do not need to spend time on proofing computer propagated translation matches that are by default out of context and they get to concentrate on their key expertise, translating concepts from one language and culture to the other. This, combined with assisting scripts and tools, allows the translator more ownership over their own work in ways that are more meaningful than just reviewing and translating words in a software.


That's a message that is often missed in the frenzy of Agile or Lean adoption. An example of that is the testing work, espcially regression testing, that is mostly done manualy and where the question "how many test cases can you execute an hour?" is the most asked question. That kind of approach clearly leads to what Mika has managed to avoid: spending most of your money in low-value added work that does not motivate and by it's very nature reduces the quality of the output. I usually compare this to the person in an old-school factory whose job is to make sure that the Coke bottles do not have too much coke in it while reviewing hundreds of bottles against a white screen...

Labels: , , , , , ,

at 21:39 | 0 comments links to this post
RSS link

Bookmark and Share

Friday, April 18, 2008

Story points explained, a good addition to the timeboxed estimation pattern

Just after writing
the post about about Never ending design discussions I found one post from Lasse about story points. I think these two posts go very well together, as story point-based estimations is what I use for the Timeboxed estimation pattern.

Labels: , , ,

at 21:25 | 0 comments links to this post
RSS link

Bookmark and Share

End the never ending design discussions: Timeboxed estimation for User Stories, a pattern in Agile adoption

In
this post, Jason explains one common problem with the estimation and planning sessions in Agile teams. The problem he describes however, is quite common and has lead to implementation of the Separate Design and Requirements anti-pattern in the traditional software development world.
So I thought I'd write a pattern about a simple and common solution that I've seen and applied to solve that problem.

Timeboxed User Story estimation

Problem:

In the first part of the planning meeting the Scrum team and the Product Owner will review the top User Stories in the backlog to make sure the team and the Product Owner share the same understanding of each User Story.
In the second part of the planning meeting the team will do a short design discussion for each of the items. The discussion should be around what needs to get done for each User Story in order to collect Meaningful Tasks and make the work clear to the whole team.
When the team gets to the definition of meaningful tasks they will get stuck in design discussions often spending too much time in the first one or two stories and then not having a complete decomposition of the other User Stories that would organize the sprint for the team.
Some consequences of this problem are:
  • missed tasks in the sprint backlog that end up not being done;
  • mis-understanding of the User Story design that leads to inconsistent design decisions;
  • unclear definition of the design for a User Story that leads to inconsistent and sometime incompatible architectural patterns in components that need to interact (especially when in the presence of Component Teams);
  • Cowboy Coding.

Context:

This pattern is applicable in the context of the planning meeting, but can be used also when reviewing a Product Backlog before the planning meeting (see Prepared Product Backlog).
The same pattern can be used to estimate any attribute of a task, such as effort, risk or business value.
In order for this pattern to be applied the team needs to agree to use the same technique. Sometimes some of the team members will refuse to use this practice by stating that it is not "serious" enough or challenging it's credibility. Alternatively people can say that with this method we cannot get "good" design, however it is important to point out that the aim of the planning meeting is not to set the "final" design, but rather the first iteration of the design and especially to achieve consensus with the team on the design patterns and architectural approaches selected. The design, as well as the product, should evolve during the sprint.
In my experience this technique can be successfully used in teams of up to 10 people during the planning meeting.

Solution

The solution is to time-box the estimation for every single User Story, not just for the meeting. Note that the team needs to agree how much time they will spend for each item they accepted for the sprint that is starting. We have used 5 minute time boxes for development stories and 2 minutes for management-related stories.
At the start of the meeting the team agrees on the size of the time box in such a way that it allows to cover all the stories needed within the length of the meeting. For example, if you have 10 stories to cover and 60 minutes meeting that means that after 5 minutes you need to move to the next story (that will give you a 10 minute buffer).
The process for each story is:
  1. The facilitator reads the story from the product backlog
  2. The teams ask questions or define tasks by talking about the design of the implementation
    • Example questions are: what modules will this story touch?; do we need help from any other team?; do we already have module X in our version control?; do we have the design for the UI?; will we need to manually test this feature or is it enough to have the automated user acceptance tests?; etc.
  3. While the team discusses the needed design changes/additions the facilitator writes down the clear tasks (example: refactor class X, change the algorithm for Y, design a view for Z, get support from the DB admin for the DB upgrade in the test environment, etc.)
    • For some tasks to be clear, the facilitator may need to ask clarifying questions. See step 2 for examples.
  4. At 4 minutes (if the timebox is 5 minutes), the facilitator will request everybody to estimate the story (using the Planning Poker method for example).
  5. If there is no consensus on the estimation, the discussion continues
    • At this time the facilitator can focus the discussion by asking the highest and lowest estimate person: "Why do you think that is the case?"
  6. At 5 minutes the facilitator will ask everybody to estimate the story and note down the most popular estimate value
  7. The facilitator closes the estimation for this story. Return to step 1.
After the meeting the team has a preliminary list of tasks (that will be improved during the sprint) and a consensus on some basic, yet critical design/architectural decisions.
Even if this method seems "minimalist", our experience is that it works well-enough even for 4 week sprints. Although, due to the size of the tasks it is easier to apply to 2 week sprints.

Resulting context

  • The first few times the team will try this technique their discussion may be very superficial, especially if the team has never had design discussions in short spurts before. This is to be expected and the experienced ScrumMaster will keep her ears open for symptoms of this during the daily meetings and call for additional design discussions during the sprint, when needed.
  • The first few times the team may feel that the process is "artificially" strict. This is a common critique. However the team should stick to the practice for at least 4 sprints before changing it or "customizing" it. Our experience is that people will adapt to the method and, after some sprints, start producing high-quality high-level design already during the short discussions in the planning meeting.
  • If the first part of the planning meeting was not enough to clarify the aim of each of the stories to be estimated the team may have to discuss the stories from the requirements perspective before they can have a design conversation. In this case the facilitator should stop the discussion and defer the estimation of that task to when the Product Owner has explained well enough the story (this is the Unclear Stories anti-pattern).

See Also (patterns and anti-patterns not defined yet):

  • User Stories for communication across functions
  • Meaningful tasks
  • Component teams (anti-pattern)
  • Cowboy coding (anti-pattern)
  • Unclear stories (anti-pattern)
  • Prepared product backlog

Resources

A good practice for the actual estimation is the "planning poker game". Here are some resources:

Labels: , , , , , , , , , , , , ,

at 19:10 | 2 comments links to this post
RSS link

Bookmark and Share

Monday, April 14, 2008

Project smells

Jason suggests that projects, in his experience, face similar problems (I'm assuming he is talking about all projects, including Agile projects).

What is your experience? What are the mistakes that happen all the time as Jason suggests?

In the waterfall world one of my favorites that happened all the time was: requirements change constantly. Can you imagine a world where requirements changes were a bad thing? I can't. I guess i've been exposed to Agile for too long (wink, wink).

Labels: , , , ,

at 18:29 | 2 comments links to this post
RSS link

Bookmark and Share

Saturday, April 12, 2008

Apple vs. Nokia, spot the differences

Being in Finland I'd love for Nokia to continue to be a big player in the mobile phone and mobile Internet access market. I lover their
N810 device (just don't get why they did not put a GSM chip in it...), and have been a loyal customer of their mobile phones.

But that is about to change (and I'm not talking about me being a customer). Indeed, more and more Apple is showing Nokia how late they are to the "consumer" game and to the whole "digital life" ecosystem. It's not enough to have a product, you have to have the right product, the one your customers want. Check this article for a comparison of Nokia's and Apple's stores in London. The pictures in the post say it all...

Labels: , , , , , , ,

at 23:04 | 0 comments links to this post
RSS link

Bookmark and Share

What does your shell history say about you?

Macintosh:~ vasco$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
63 svn
56 cd
47 ls
26 sudo
26 man
23 ruby
17 find
15 /usr/local/mysql/bin/mysql
12 dir
9 set

"svn" is explained because I'm not familiar enough with RADRails in Eclipse and it is really easy to use command line for two word commands anyway :)
"cd" and "ls" are a waste of time... Something to improve here.
"sudo" and "mysql" just say that I run my development environment from the command line. "ruby" on the other hand tells you that with WEBrick reloading the rb files on the fly everytime you change them I don't need to re-start the server to change my web-app! ;)

What does your shell history say about you?

PS: "dir" is a common dyslexia for those of us that have suffered many Windows years...

at 22:41 | 2 comments links to this post
RSS link

Bookmark and Share

The Green Shift Anti-Pattern

This is a pattern that effectively prevents any team from succeeding, and in many cases just causes a whole organization to behave in a dysfunctional way.

Check it out. Has it happened to ? No, honestly!
Blogged with the Flock Browser

Labels: , , , , , ,

at 07:50 | 0 comments links to this post
RSS link

Bookmark and Share

Friday, April 11, 2008

Don't blame, reward people that surface their own mistakes!

In Lean thinking errors or mistakes are seen as opportunity for improvement and growth. But in lean, mistakes don't come alone, they also provide an opportunity for the team to create a poka-yoke tool/device. Poka-yoke stands for "mistake proofing", i.e. making sure the same mistake does not happen again. This can only be done by changing the process or tools.

All of these things stem from the most important value in Lean Thinking: Respect for people.

When Toyota started exporting their ideas outside Japan they found out that in some countries the culture was to "blame", not to reward the honesty of admitting a mistake.

There's this story (thanks for the link Jukka!) of an american enginner (let's call him Mike) working in Japan. Mike was working on the line and while assembling a part in the car he scratched the paint. Influenced by his culture he was afraid of admitting the mistake, so he thought twice before pulling the andon cord (the device that notifies others when there is a problem). After a few seconds of struggling with the dilemma he pulled the cord and waited. The team leader immediately came to the workstation and was able to fix the defect quickly. The line did not stop.
At the end of the day while the daily meeting was going on the team had brief exchange in Japanese that Mike did not understand, but his fear was that they were just criticizing him in Japanese so that he would not feel so bad. He was wrong. Soon after that the team started applauding and looking at Mike, he was confused. When asked, the supervisor clarified: "the team was proud of you admitting the mistake and wanted to express that!".

This is why mistakes should be "admitted" by those who make them, not just "blamed on" the people that made them. Admitting the mistake and wanting to improve based on the learning is the most important part of surfacing the mistakes and "stopping and fixing". A culture that only assigns blame for mistakes will only create a need to hide those mistakes.

Let people admit their mistakes and create a welcoming environment where people actually will be proud of surfacing and fixing their mistakes. Don't just blame, blame kills improvement.

Update: Updated to add link to the story about Toyota.


Labels: , , , , ,

at 09:48 | 2 comments links to this post
RSS link

Bookmark and Share

Thursday, April 10, 2008

The Proxy Product Owner, a pattern in Scrum adoption: version 1

Below I try to describe a pattern that I've faced and have seen in other teams in the context of an Agile transition.
See the explanation section for more details on each of the sections in the pattern.
If you have faced similar situations let us know of your own story in the comments below.

Proxy Product Owner

Problem:

There are 2 or more Product Owners that give work to the Scrum team and the Scrum team has several systems to maintain. Each Product Owner owns only a subset of the systems the team works on and is only interested in the systems she owns.
The team is faced with unclear priorities, Product Owners who do not want to agree on the priority of each other items, and because each Product Owner has their own Product Backlog, the team has a hard time coordinating the work that they need to manage sometimes leading to the team creating their own Backlog that is hidden from the Product Owners, and where the real priorities are set without their knowledge (this is the Secret Team Backlog anti-pattern).

Context:

This pattern is applicable when the Product Owner community for one development team can not reach agreement without the intervention of a third person that will help them define the right priority for all the backlog items.
This pattern applies equally well if there is a decision within the organization that some products, and therefore the respective Product Owners, should receive a higher level of service.

Forces:

  • Typically the team is paralized or hampered in their effort by the lack of clear priorities.
  • In some cases the team ends up delivering features that are not in line with the company or customer needs
  • The ScrumMaster will spend most of her day managing the Product Backlog and answering uncoordinated requests from all stakeholders
  • Stakeholders include the Product Owners, but in some cases the Product Owners don't act as a proxy, but rather delegate their responsibility in the users/customers they represent. In this case the team and the ScrumMaster are faced with many conflicting signals about what the real priorities are.

Solution

The ScrumMaster takes charge of the Product Backlog, which in this case will become a Team Backlog, in that it includes items for all of the systems that the team manages, not just one product.
The first goal for the ScrumMaster is to get the Team Backlog in shape so that the team can start working from the Team Backlog without having to spend many hours getting the Backlog In Shape.
Once the team can consistently take items from the backlog without a need for large interactions with the Product Owners, then the ScrumMaster can start using the techniques described below for the proper prioritization of the Backlog by all stakeholders.
When several (2 or more) Product Owners are involved in the prioritization of the backlog it is important that all of them understand the need to serve all Product Owners and not just one, therefore the prioritization technique should reflect that fact.

Equal weight for all Product Owners

In this case all Product Owners have equal importance for the organization and therefore they should be assigned the same amount of decision power. That is done by giving each Product Owner 1000 points that they can distribute among all items in the Product Backlog. Each product owner knows that all others have the same amount of points to distribute, therefore they will be forced to "invest" more points into the stories/use cases/backlog items that they really want to get done in the next few iterations.
Each Product Owner may also invest points into other systems than their own, if that will help them get some feature in their own systems.

Different weight for each Product Owner

In this case one Product Owner is considered more important. He is given a larger percentage of the points available. The points given to each Product Owner should be similar to the company investment level decisions. For example, if a Product Owner's product is to receive 70% of the investment, the she should be assigned 70% of the points available for distribution among product backlog items.

Resulting context

  • Once the ScrumMaster takes ownership of the Product Backlog the Product Owners will now focus on influencing her and get her to make decisions that are favorable to their needs. This should be avoided and the ScrumMaster should follow as much as possible the real results from the the prioritization done through the distribution of the points by the Product Owners
  • In some situations some Product Owner will not do the prioritization before the Planning Meeting. In this case the ScrumMaster has a choice of letting the Product Owner assign a subset of her points during the meeting -- as not to delay the meeting too much; or then not allowing late prioritization, in which case the team will not work on the systems owned by that Product Owner.
  • For this pattern to be implemented the ScrumMaster will have to spend a large part of each day managing the Team Backlog and communicating with the Product Owners. The team and ScrumMaster should be aware of this and decide to invest the ScrumMaster's time in that task.

Example

The ScrumMaster in one of our teams is frustrated with the Product Owners because they are never present, and hardly communicate with the team except to shout at them when something critical needs to be worked on "yesterday".
The ScrumMaster has taken the ownership of the different Product Backlogs and joined them into a Team Backlog, where items for all products are collected.
In this example, the team has not enforced a Force Ranked Priority on the backlog or Sprint Backlog, which then leads to a more difficult decision on the real priorities for each item that ends up in the Sprint Backlog. This leads to the stakeholders, who are not engaged, classifying every item as Critical or High priority. This situation then leads to the team in practice deciding which items are done first and which Product Owners are served first.

See Also (patterns and anti-patterns not defined yet):

  • Team Backlog
  • Backlog In Shape
  • Planning Meeting
  • Secret Team Backlog anti-pattern

Pattern format explanation

In "Name" I give a name to the pattern.
In "Problem" I describe the problem the team is facing in the form of a root cause and a set of symptoms that may be detected and lead to this problem.
In "Context" I explain where the pattern is applicable.
In "Forces" I try to describe the constraints or forces that the solution has to take into account.
In "Solution" I try to describe the instructions and practices to be used to solve the problem as described.
In "Example" I briefly explain the case of one team at work that has faced this problem and how they solved it.

Labels: , , , , , , ,

at 22:50 | 1 comments links to this post
RSS link

Bookmark and Share

Tuesday, April 08, 2008

Personal Scrum or Work 2.0


So, I've been inflicting Scrum on myself.

This is my "eat your own dog food" because I'm an Agile Coach at the company where I work, which in practice means that I try to work with teams and help them with Agile adoption, and in some cases with the Agile development.

For me to preach Scrum and not do it would be at least incoherent, but I can think of even less nice ways to put it.

So, back to the story. I'm using Scrum patterns for managing my own work. Let me explain this a little bit. I'm following a method for the management of my personal work that resembles and is largely based on the patterns that we see in Scrum.

Here's the key points of how it works:
  1. I have the weekly planning (yes, I'm using weekly iterations/sprints) every week on Monday morning. This is where I look at my backlog (personal and team) and the list of meetings for the week and I plan what I will be doing that week. The weekly plan I put on the wall with post-its.
  2. Every day in the morning (before opening Outlook) I read my task board on the wall and list for myself what I wil try to accomplish during that day (only that day). This becomes my "daily plan" for the work to be done. And the fact that I review the plan daily also helps me to
  3. On Friday I finalize my sprint, do the personal retrospective and review if there's something from that retrospective that I want to add to my Backlog.
There are more details to this, but these are the key points. I'll write about the details later.
The Scrum patterns applied with the above items are:
  • The planning day (point 1 above), which in my case is a planning hour (it takes between 45 min and 1,5 hours)
  • The daily check (point 2), which is my review of the task board in the morning and the resulting "daily plan"
  • The retrospective (point 3). Where I analyze my work week and collect "TRY" items (as in Cockburn's retrospective agenda) that I will implement during next week.
This way I stay familiar with the mechanics of Scrum (not all, but the key points) and have a method for managing my own personal work.

The results have been good. I've developed the concept of personal capacity (velocity in XP), which tells me what I can commit to and gives me a good way to communicate with my stakeholders about what I can and cannot accomplish in one week of work.

As a result of knowing my capacity I can now be proactive and manage the "pipe" of work for the next few weeks (I'm keeping a backlog of three weeks for short term actions in a limited queue: credit for Mary Poppendieck for bringing that up in the training at our company).

Maintaining the limited queue for the next 3 weeks in turn helps me not just avoid over committing to work during the ongoing week, but hopefully also for the next three weeks.

The biggest value I get out of the system though, is that now I really am in control of my work and can make informed decisions constantly. I have a proper time management system in place!

This method I call Personal Scrum, when used to manage my personal work, or Management (as in Work Management) Scrum, when used to manage the work of a management team.

Labels: , , , , , ,

at 19:53 | 7 comments links to this post
RSS link

Bookmark and Share

 
(c) All rights reserved