Agile Thoughts

Recently I was involved in an interesting discussion on how you would start a dedicated test team from scratch to enhance the focus on quality. I went into the discussion certain the new team would have most in common with the project management team and therefore should reside under project management until it was large enough to stand on its own.

To my surprise my counterpart in the discussion argued that the new team should initially reside under the architects until it was big enough to become its own. After listening to the argument I saw that the decision wasn’t as clear cut as I have originally thought.

After some heated discussions back and forth we realized that we were actually talking above two different disciplines when we talked about test and we had fallen in the trap of assuming that we were actually talking about the same thing. I was talking about test from a functional user perspective where my counterpart was talking about technical test such as unit testing, performance test etc.

In the case we discussed requirements are gathered as user stories. One of the hardest parts of writing good user stories in my opinion is to get the Confirmation part (Accept criteria’s) right in a timely manner. By timely I mean early enough to function as validation of the requirement and as design input by coining the requirement from a different perspective. I think that early validation is essential to an efficiently run agile project.

On the other hand you also need to shorten the feedback cycles on a code level to be able to respond timely in the short time span of an iteration. Without automated unit tests you tend to postpone the code integration and quality assurance activities until late in the iteration, much like in a traditional Waterfall project. Thereby you run many of the same risks as in the traditional project, however in shorter cycles making it a tiny bit less dangerous.

Now the million dollar question is “What is more important if you can only have one?” Personally I find it very hard to answer this question. I think that both disciplines are equally important. You need the early verification to make sure you are building the right product, but you also need constant feedback from the code to make you will actually be able to deliver working software at the end of the iteration. Where would you start, if you could only do one or the other?

After sitting in on a research results presentation on agile requirements validation done by Rosalva Gallardo the first “real” session I attended at Agile2009 was Mike Cohn’s Monday morning session on Prioritizing Your Product Backlog.

Mike kicked off the session talking about the right level of stories (requirements if you will) for prioritization followed by discussing four different techniques for prioritizing. During the session there was time to do two prioritization exercises in teams making the message stick.

The key takeaway was that prioritization should be done on the appropriate level dependent on where you are in the project. The level is not the same for prioritizing at Iteration (Sprint), Release and Future Release level. To achieve this related user stories are aggregated into Themes and smaller stories that are part of a bigger story is rolled-up into the bigger story called an Epic. At the user story level you are often not able to prioritize one story against another. Mike used the example of a word processor where you wouldn’t ask a user to prioritize between getting the A or E key since the processer has not or very limited value without one of them. But at a higher Theme or Epic level users are perfectly capable of discussing and prioritize. Mike gave the example of prioritizing between having Tables or Undo functionality. The word processer could work perfectly without one or the other although users might miss the features dependent on their preferences and needs. If they are writing a novel they might prioritize an undo function over tables and vice versa if they are writing more technical stuff.

 After discussing the appropriate level of prioritization Mike explained four different approaches for prioritizing including Theme screening, Theme scoring, Relative weighting and Kano analysis. All four approaches have their application, but I personally prefer relative weighting. In relative weighting you score each theme on a scale from one to nine on both their relative benefit if implemented and relative penalty if not. The two values are added giving a total score that compared to the implementation estimate can be used to prioritize what themes to implement first.

Currently my company works with a relative scoring system where the most valuable theme or story is assigned a score of a thousand and all other themes are given a lesser number equivalent to their relative value compared to the most valuable theme or story. The approach is working pretty well, but sometimes it can be hard to get users to assign lesser values. Following the talk I’m therefore considering trying Mike’s relative weighting system out on a project and maybe adopting it as the company standard I find it works better. I would however add a 2-1 weight in favor of the benefits compared to the penalties because I think the positive attribute should be the driving force and it’s also often the positives that brings the highest value and excites the users the most. To do this you multiply the benefit value by two before adding it to the penalty value giving you a total score to compare to the cost.

In a tweet posted immediately after the session I scored it a four out of five. With 20-some sessions ahead of me I wanted to make room for better things to come. With approximately 70% of the conference behind me I am not sure I’m going to need the full scale. Mike’s session was certainly one of the best and most applicable I have attended so far.

To find out more check out Mike’s presentation on his site http://www.mountaingoatsoftware.com/

Related Posts:
Agile2009 – A buffet of Agile

Today the weather has changes dramatically in Chicago and we now have rain and thunderstorms. Not that it really matters since I will stay indoors and enjoy the agile extravaganza at Hyatt hotel in Chicago.

Yesterday evening I was hoping to do some writing on the sessions I have attended the first two days. Instead I “fell” into a discussion with a couple of colleagues on how to combine Agile (Scrum), CMMI (Level 5) process improvement and Lean. Danish company Systematic is doing some pretty cutting edge stuff on combining the three and if you are at Agile2009 you might want to check out Carsten Jakobsen’s talk (Scrum and CMMI: from Good to Great – are you ready-ready to be done-done) on the subject today.

Today my schedule is influences by some great input from a couple of the project managers at our company. I really appreciate that they have taken the time to browse the extensive program and identified sessions that fit our organizations agile adoption strategy.

Wednesday Morning:

Pragmatic Personas: Putting the user back into user stories by Jeff Patron because it’s key to working with user stories that the user roles are defined as clear as possible and I want to investigate if lightweight personas is the tool to achieve that.

Agile Metrics by Dan Rawsthorne because correctly applied metrics is a great way of taking the temperature on how a project is running and visualized appropriate metrics can change a team’s behavior just by raising their awareness.

Wednesday Afternoon:

Handling Non-Functional Requirements on an Agile Project by Ken Howard because handling classic user stories is pretty straight forward, but often non-functional requirements “comes in the way” and teams struggle to fit them into the streamlined process they have for functional requirements.

From Concept to Product Backlog – What Happens Before Iteration 0? By Gerard Meszaros because we mainly run shorter projects (3-9 months) and often encounter new clients/people who does not have experience with agile and it’s therefore imperative that projects gets off to the best start possible and iteration 0 activities is a big part of that.

Related Posts:
Agile2009 Day 2 – The Festival Continuous  
Agile 2009 – A buffet of Agile

It’s Tuesday morning in Chicago and it looks to be another sunny day. It would be a shape to spend it inside air-conditioned conference rooms if it wasn’t for the number of exiting sessions that are available again today. Plowing through the program I have come up with the following shortlist of sessions to choose from today:

Tuesday Morning:

Keynote “I Come to Bury Agile, Not to Praise It” by Dr. Alistair Cockburn because Alistair often has some interesting views on things and with the title it should be guaranteed that this talk is no exception.

Death by Scrum Meeting by Pete Behrens because Scrum meetings are the heartbeat of a project and it’s vital that people are engaged in the meeting to get the maximum performance out of the team.

Risk and Risk Management – Theory and Practice by Chris Matts and Todd Little because it’s an important topic that has not been fully explored in an agile context. Most agilelists claim that risk management is build into an agile process and no further effort is needed. The few who actually do risk management  in the agile community does it the old fashion . Hopefully Chris and Todd will bring something new to the table.

Tuesday Afternoon:

Barely Sufficient Portfolio Management w. Todd Little and Kent McDonald because portfolio management is something that is often overlooked in agile where all the processes focus at the individual project level.

Facilitation Patterns and Anipatterns by Steven “Doc” List because being a good facilitator is key to any agile leader if he/she is not to fall back in the old command/control style management when the going gets tough.

Diagrams for understanding and improving Agile practices by Bonnie Aumann and Arlo Belshee because we are at a point where a measurement of how well the individual practices we have implemented works could help in our quest for continuous improvement.

My takeaways from Monday and today’s sessions will follow later.

Related Posts:
Agile 2009 – A Buffet of Agile

I’m now in Chicago for the Agile 2009 conference. After spending some time in the city yesterday (what a place) I am now trying to figure out what sessions to go to later today. Originally I intended to do all the planning before leaving Denmark, but general lack of time and an overwhelming number of sessions to choose from have left me postponing it until now.

In order to get the most out of this “all you can eat buffet” of Agile where it’s impossible to taste all that’s on the menu I have tried to set up a simple criteria for deciding if I go to a session or not: It has to be relevant my company’s agile adoption process. We are two years in and are delivering successful projects using agile techniques. We have covered all the basics and I will therefore be looking for sessions that are relevant to our next step (moving from a team-by-team implementation to the enterprise level) or sessions that specifically cover areas where we could improve our current practices.

Today I am planning to go to the following sessions:

Monday 09:00-10:30:

Agile Validation is Continuous and Collaborative: A Field Study of Agile Require by Rosalva Gallordo-Valencia because it’s the only session Monday morning and I want to get off to a flying start. Hope to hear some interesting findings.

Monday 11:00-12:30:

Prioritizing Your Product Backlog by Mike Cohn because Mike it’s so important that the backlog is prioritized correctly to make sure the highest business value is produced and Mike might just come up with some new ideas for doing that.

Monday 14:00.14:45:

New Approaches to Risk Management by David Anderson because it’s often claimed that Risk Management  is build in to an agile project and still projects gets into trouble and I hope David has some valuable input on handling those risks threatening the project.

Monday 14:45-15:30:

Weaponized Scrum by Michael Marchi because the title is really cool and because the description of a person having championed agile adoption in his organization to the point where it transforms from grass-roots to management directive fits me perfectly.

Monday 16:00-17:30:

Zen and the Art of Software Quality by Jim Highsmith because Quality is a focus area this year at our company and I hope Jim can provide me with new ideas for improving quality.

If you have read this far you must be interested in what I get out of attending Agile 2009 (or amazingly bored). Check back later during the week and I will have a review of the sessions I have attended ready for you.

As mentioned in my post Agile Reapplied: Preparing for an Exam I am fascinated by application of agile principles to non software development disciplines. I find myself doing it constantly and often with great results. This post is about how I revitalized our team meeting by applying simple agile principles like collaboration, business value driven prioritization, embracing change etc.

Before discussing the details a little background information seems appropriate. Apart from being responsible for our project management model and leading my own client projects, a large part of my job as Head of Project Management is to lead my team consisting of nine talented and skilled Project Managers. The team is located at two different physical locations three hundred kilometers apart.

When I took over the team two years ago there was little focus on project management craftsmanship and on collaboration and knowledge sharing between the project managers. To change this and kick-off the new team I arranged a project management day where we discussed both agile and traditional project management and how we wished to define us as a team.  Since the first meeting we have meet approximately monthly spending an entire day to discuss different aspects of project management. We also use the meetings to support each other if we have had rough times on our projects. The team is a safe haven where we got each others back. And now let’s discuss the details of the team meetings.

Stand-up Status:

Since we only meet once a month and work from different locations it can be difficult to keep updated on what the other project managers are doing. To share some information on what’s going on we start every meeting with a quick stand-up status. Each project manager focuses on answering the questions; what is my biggest achievement since the last meeting and what is currently my biggest challenge that my fellow project mangers might be able to assist in solving. We try not to solve the challenges during the stand-up, but some of the other project managers have had similar challenges and are able to give advice on how to navigate.

Meeting Subject Backlog:

Like any other agile project our backlog is a central tool for prioritizing what to discuss at the meetings. Between meetings new ideas are put into the backlog on the team site with a description of the topic and information about who will be able to facilitate the subject. Every project manager is allowed to add both subjects they can facilitate themselves and subjects they can´t but are interested in hearing about.

Business Value Driven Prioritization:

At the end of every meeting we discuss the items in the backlog to decide what to discuss at the next team meeting. Sometimes we “just” agree on what to put on the agenda and other times we do dot voting to decide. Regardless we end up with an agenda that has the highest possible value to the team. This sometimes frustrates managements when they want to speak at our meeting and I tell them that they will have to “sell” it to the team and get prioritized. Off cause I have to make exceptions when they insist on stage time, but I try to stick to the concept as much as possible.

At every meeting I have information, including team performance data, which I want to discuss with the team, but I don´t make an exception from the concept just because it’s something I want to share. This means that I only get to share the team performance data if the team thinks it interesting enough to spend time on. Luckily they have so far, but it also serves as a constant reminder to me to make the information interesting.

Embracing Change:

When we start of a meeting we decide which of the topics on the agenda is the most interesting and we start with that topic. We don´t work with a timetable unless we have external speakers attending the meeting. This means that we can decide to spend the entire meeting discussing only one or two topics if we find them sufficiently interesting – this happens more often than not. Previously when we followed a timetable we often found ourselves breaking off a valuable discussion to move on to the next topic. Often we never returned to the discussion getting the entire value from it or we found it hard to pick-up where we left off. The backside is off cause that some topics are postponed to a later meeting (put back in the backlog) and the person responsible have prepared for nothing. We accept this because of the value we get from the reprioritization and often the postponed topics are then selected for the next meeting.

Reflection Sessions:

At every meeting we do at least two reflection sessions to evaluate how the meeting is progressing. The first is a short reflection just after lunch. This serves two purposes. First of all we have time left (approximately half the meeting) to change things if there is something that could be improved to provide more value. Secondly it’s used to share information about what was discussed over lunch. With ten participants one cannot follow every discussion during lunch and often others have discussed new valuable insights on topics discussed during the morning while having lunch.

The second reflection is held at the end of the meeting where topics for the next meeting are also discussed. This is a standard reflection session focusing on what we should keep doing and what we would like to start doing at the next meeting. Actually the lunch reflection session was a result of a reflection and now we find value in doing it at every meeting.

Final Thoughts:

Since we changed the meeting structure from a more traditional structure with a solid timeline to a subject value driven structure we have found that we get more value from the meetings. People look forward to the meetings, prioritize participating and are more engaged in the discussions than previously. Personally I also find myself speaking less than I did previously which is great – now it’s not only my views and experiences that are shared, but the entire teams.

Photo credit: http://sti.epfl.ch/webdav/site/sti/shared/sel/ee_meeting.jpg

During April I read a lot of excellent blog postings on Project Management and Agile and I want to share some of the best with you. I hope you can find inspiration from them too. If you think I have missed out on some of the really good ones – I’m not reading every single agile blog on the web – please feel free to add a link in the comments.

• Why Bother Looking At Social Media For Use In Projects @Project Shrink


• Why Agile Development Requires Agile Architecture @ Inside Architecture


• How I failed as a Product Owner and the lessons I learnt in theprocess @ Analytical Mind


• First Order Agile Scaling, Second Order Agile Scaling and More Second Order Agile Scaling @ Leading Agile


• Why Slow Start is Project is Such a Great Idea @ Pawel Brodzinski on Software Project Management


• Leader vs. Ruler: Which One Are You? @ noop.nl

You can find all the posts I bookmarked during April via my delicious account: http://delicious.com/meolesen. You may also want to check out Bas de Baar’s collection of top Project Management posting in April @ http://blog.softwareprojects.org/top-project-management-postings-april-2009-1377.html

Photo creadit: http://www.ibspro.net/wp-content/uploads/2008/07/blogging.jpg

Leading agile bloggers Jurgen Appelo has taken a great initiative by conducting a survey about agile practices. The survey is a follow-up on Jurgen’s big list of agile practices and focuses on which practices are most widely applied and which are considered to be the most important – as Jurgen puts it:

This survey is NOT about your company’s size, industries and other boring stuff. It is about the things that are most dear to us:

• Which practices are really agile?


• Which practices are really important?


• Which practices are really applied?

There are six parts in the survey (requirements, design, construction, testing, process and organization). You can choose to do them all or skip certain parts. I hope you will help Jurgen and the rest of the agile community understand which practices are really used and which are not by participating in the survey.

The survey is available on his blog.

Photo credit: http://www.itap.purdue.edu/tlt/idc/tips/current.cfm

On my Top 5 list of “always to use agile tools” (not that I have one, but if I had) is the burn down chart. I find time and time again a visible updated burn down posted on the wall in the project room and on the project team site to be one of the simplest, yet powerful tools, I can use. An updated burn down helps facilitate communication among team members and it keeps the team focused on delivering business value.

When I first discovered the burn down I adopted the simplest possible burn down with one line representing the target to be completed in the iteration and one representing the progress of completed tasks. This is the text book version and probably the most widely used burn down. It gives a very clear and unmistakable view on how the team is doing compared to what they planned.

 Soon after adopting the burn down I started “enhancing” it. I added lines to show scope changes, changes in resources etc. Soon I had an advanced burn down with 6-7 different lines that could tell me everything about the project and almost brew coffee under water. Unfortunately I was the only one who could read it and it quickly lost its value as a communication and collaboration tool.

After toying with different customizations I went back to the simple version, but with ONE small extension (see chart below). Besides tracking completed work I also track the amount of work in progress. Tracking both gives me a lot of information about how the team is doing without losing the readability of the chart. If the gap between work in progress and completed work widens considerably I consider it a risk to the project. It indicates that the team starts new tasks rather than finishing what they have already started. In the example chart below the gaps between work in progress and completed work is considerable different at the red and green arrows. A large gap is a problem because completed work has a number of advantages over work in progress:

• A completed task can be integrated with the rest of the system.


• Completed tasks are a more reliable progress indicator than having to ask a developer how much progress she has made on a task i.e. in percentages.


• The risk of uncovering unexpected complexity in the iteration shrinks with every completed task.


• Completed features can be demonstrated to the client for feedback.


• A completed task gives the team one less thing to worry about in the iteration.


• Completing tasks motivates and keeps project management happy.

Pure Agilist might argue that only completed work should be measured since it doesn’t matter if a task is 10% or 90% done when the iteration is completed and the solution is scheduled for release. A partly done feature should not be released regardless of how big that part is. Although I understand the argument, I still find it useful to have both metrics represented in the burn down. It raises the whole team’s awareness of how we are doing in the iteration.

Although the burn down described above works well for me I would always recommend people new to using a burn down to start with the simplest possible burn down and see if it does the job before getting creative. If it doesn’t it’s probably not the burn down that’s the problem and adding more metrics to it will most likely not solve the problem.

Finally I’m interested in hearing about your experience. Are you using the standard burn down or have you also customized it. Please drop me a couple of lines on what has worked (and maybe just as interesting) what hasn’t.

In order to do a decent job leading projects I have found that there are several tasks that I need to do on a daily basis. Past projects where I was able to do the tasks consistently by far outperformed the projects where I was not.

My daily Project Management task list:

1. I have spoken with each member of my team.
2. I have spoken with my customer(s).
3. I have taken actions to remove any impediments highlighted by my team.
4. I have updated and published progress information.
5. I have updated and published minutes/action items for any meetings held within the last 24 hours.
6. I have reviewed project risks and taken appropriate actions.
7. I have had fun and feel confident about tomorrow.

The first two tasks on my list have to do with communication. If I was only to have two tasks on my list one and two would be the list. I need to know what is going on in the team and with my customer(s) in order to lead the project. Even just a small chat with each team member individually gives great indications on how that person and the project are doing.

The third task has to do with the fact that I consider being a servant to the team one of my most important roles. I can’t develop half as effectively as my team members and my time is therefore better used making sure that they have optimal conditions to be productive.

The fourth and fifth tasks also have to do with communication, but in a different sense than tasks one and two. In order to make sure the team and other involved parties are aware of the current state of the project they need to be informed. I prefer to use a burn-down chart to display progress information. I post it on the wall in the project room and on the project collaboration portal for anyone involved to see.

The sixth task has to do with making sure that the project does not run into serious trouble caused by an unforeseen event that could have been prevented. At least once a week I go over the physical (electronic) list of risks, but I try to give it some thought daily

The final task might seem silly, but I think it’s extremely important to be able to have fun on a project, but also to be able to go to sleep at night confident that you are well prepared to face whatever challenges are thrown at you the next day.

When I notice that I can’t perform the tasks on the list above every day, it’s an early warning that the project will suffer if I don´t do anything about it.

Photo credit: http://www.humphriesmortgage.com/pages/Checklist/images/checklist.jpg