The agile meeting dilemma

If you’ve been doing agile, and especially Scrum, you’re well aware of the meetings that are required to keep things running smoothly: (1) the iteration planning session, (2) the daily stand ups, (3) the iteration review session, and (4) the iteration retrospective. If you follow scrum by the book, a two-week iteration would include 18 hours of meeting time (8 hours for planning, 15 minute daily stand ups, 4 hours for review and 4 hours for a retrospective). That’s 22.5% of an 80-hour schedule for an iteration that is consumed by meetings. Many people argue that this is too much time spent in meetings over the lifetime of a project, especially if it’s an overhead or operational expense. I don’t necessarily disagree. However, these meetings are essential to effectively delivering value to clients and to the continuous improvement of a team’s agile practices. So, how do you handle this dilemma of balancing meetings that enable practices with project budgets, etc.? The answer: Use the scrum mantra “Inspect and Adapt”.

Our agile teams have examined our meetings and have effectively reduced our meeting time to the following: 2 hours for iteration planning, 15 minute daily stand-ups (and they’re usually shorter than that), 1 hour for our iteration review (usually shorter) and 1 hour for a retrospective (again, usually shorter). This amounts to only 6 hours (or less) of meetings for every two week iteration or 7.5% of the iteration spent in meetings. We think this is a manageable amount of time to dedicate to the various necessary activities of scrum to be both efficient and effective. I think that anything shorter than these times would probably start affecting the value of these agile practices. We are still planning without any problems and we are able to review two weeks worth of work in 1 hour or less with our clients. We have also found that 1 hour is more than enough for our retrospectives. Currently, we include these meetings in our project costs because we bid our projects as agile projects. Our clients are aware of the value these meetings provide their final product.

So, based on our experience, I would suggest really examining the value of the meetings you use to keep your agile practices running. If you and your team find that you are merely filling up time-boxes to do scrum by the book, inspect and adapt. And remember, if you adapt your meeting times to be shorter and you are finding that you need more time for a review or for your planning session…inspect and adapt. Scrum is an imperical “process”…keep experimenting with your meeting times until it feels right for you, your team and your product owner. And, if you can agree with your client that these are project related costs that provide value and not overhead or operational costs, all the better for you and your client.

Pragmatic method for increasing your team communication level

Creating Shared Understanding with Cards
I and Angela Martin are proposing a session for the Agile 2008 conference. It is the most important conference of the agile software development world.

During our Getting Shared Understanding with Cards we are going to present several extremely effective and very pragmatic ways for raising the development team productivity with the help of just paper cards.

We need your support

This year is different in that everybody on the web can (and hopefully will) vote for the sessions and add his or her comments.

Have a look at our session proposal and if you like it, vote for it (voting will require creating an account on the conference web-site).

P.S.
There are many other sessions that you might find worth reviewing or voting for. For example, there are a couple of sessions (to visit this link you’ll have to register on the site) proposed by our semi-permanent author Chris Spagnuolo. There are also a lot of session proposals that contain excellent papers attached. For instance, Jeff Sutherland’s proposal contains an impressive study of effectiveness of the distributed Scrum implementations.

What’s in your backlog?

This morning I was looking over several of our project backlogs and noticed something that really caught my attention. In addition to user stories that addressed the functionality we are developing, our project teams have been adding stories to the backlog that have nothing to do with project tasks (or maybe they have everything to do with project tasks). The stories are about improving processes and practices, organizational issues, team matters, and even the project structure.

I was really happy to see this. It proved beyond a shadow of a doubt that our project teams are becoming mature agile practitioners. They’ve realized that the issues uncovered in their retrospectives are important enough to warrant being put into a backlog. This ensures that they won’t be ignored or forgotten about when the retrospective is over. It puts the issues front and center and on par with development tasks. And, it makes sure that we are actually going to do something about them within a time-boxed period.

So, what’s in your backlog? Is your backlog filled with only development tasks or does it include stories about improving your team and your practices? Take a look today and consider if you need to elevate these non-development stories to a higher level.

XP Practice: Test-First Programming

Test-First Programming (TFP) and its sometimes more known related practice Test-Driven Development(TDD)  are not very usual for the traditional software development cycle. Test-driven development simply means creating tests before writing the code they are supposed to test. A canonical test-driven cycle is as follows:

  1. Write a test for the functionality you are going to implement
  2. Write as little code as possible to make the test compile. Make sure that at this step the test fails
  3. Write minimal or almost minimal code needed to make the test pass
  4. Once the test passes, refactor the code to make it better, prettier or simpler. The test and other existing tests will guard against accidental functionality breaks during the refactoring process

Test-first programming is the extension of TDD to the whole attitude to the software development. TFP means that whenever there is a need for changing the software on any level, it is better done in the small completed chunks and every change should be accompanied with the corresponding acceptance criteria. On the code level it means test-driven development, on higher level it means working in small user stories verifiable by the acceptance tests, ideally by the executable acceptance tests.

The point of both TDD and TFP is in making the change specification being not a bloated document, but small, as concrete and visible as possible. Test-First Programming is certainly a no silver bullet in the software development, but when applied diligently is one of the most effective elements in the agile toolbox. A concrete, small and ideally executable specification is a good aid against programming by coincidence.

Links

This page is a part of the Extreme Programming overview

Micromanagement in Agile/Scrum. Sprint to sprint control

There are not that many people who like micromanagement. No surprise that the fear of day to day micromanagement scares some people off the agile processes. That is not the only way agile processes can look micromanaging. All the agile processes employ the idea of iterative and incremental planning on pretty much every possible level. Scrum Product Owners can change the project priorities every 14-30 days, in Extreme Programming, the usual iteration length is just one week. Naturally the possibility for the rapid shifts in the priorities can make it difficult for the team to design and build a good architecture and work at a full possible speed.

Development team productivity

The sad or not so sad truth is that agile methods are not aimed at maximizing the development team productivity. It is one of the welcome side effects that can happen, but that is not the grand goal. One can even say that the agile doesn’t care about the development team productivity at all (you anyway cannot measure it properly). What agile is focused on is the speed of the business value realization. It is the team productivity towards the current understanding of the business value is what matters. Whatever fast the one could move it doesn’t matter if doesn’t want where he wants to go. Extra team speed that they could have if the goals were more fixed, just doesn’t count in the end if it was not the real goal.

Lousy requirement management

So, is agile invented for helping the lousy requirement managers to get at least something useful for the customer at a cost of the developers’ time, headache and inability to see really long forward? You might call it this way, indeed. Agilists though prefer thinking that capturing the actual customer requirements upfront is impossible whatever good analysts you’ve got and even if you manage to capture requirements reasonably well, the real customer goals and/or market situation can easily change during the course of development (think what iPhone did to the phone buyers expectations). The need for agile comes from the poor predictability of the real world, not from the hordes of poor managers existence.

The Agile balance

Agile methods seek balance between the need not to distract developers every day and the need to adapt to the changing world complexity. In a way that is micromanagement, but in a strictly limited manner. A team always has at least an iteration to go without interruptions and a good product owner always tries to make it clear which requirements are most likely to be changed. Naturally, if your you have to satisfy the frequent changes of the customer and market desires, you might have to learn the evolutionary requirements, evolutionary design, test-driven development, continuous integration and other good old agile engineering practices.

Your experience

Does it make sense in your environment? Is there a way to both make developers happy about their software and satisfy the always changing customer requirements?

Micromanagement in Scrum. Day to day control

There are quite many people to whom agile processes look like a lot of micromanagement: developers have to report on their actions every single day, management picks its nose to every feature, wants the team to report with demos every two-four weeks and has problems allowing to spend a couple of months on thinking through and building a good architecture. Sounds like micromanagement, doesn’t it?

Micromanagement devils

The devil is as always in the details. One might call the above description a micromanagement, but it is very different from the traditional meaning of the term. Micromanagement in Scrum indeed happens if by micromanagement you mean staying in direct control over relevant things at both high and low level of abstraction. The trick is that direct control at different levels is strictly separated, employed by different people and serves the different purposes. Team is micromanaging its daily actions on the daily level and management micromanages the release content on the iteration level. Doesn’t look like a traditional micromanagement by a pointed-hair boss telling you when you are allowed to change the function name, does it?

Team level

On the team and daily level there are daily standup meetings, where team members gather to synchronize with each other and figure out how to help the ones with the biggest problems on the way. There is no real reporting and the whole reporting part – “What did you do since the last meeting?” question – should take the smallest part of the meeting and its main purpose it to give context for the subsequent “What are you going to do until the next meeting?” and “Are there any impediments on the way?”. There is no commanding boss that makes decisions, Scrum Master plays a facilitator role only. Is it micromanagement then? Yes, if making the team aware of its daily actions and allowing it to take corrective actions is micromanagement.

Your experience

How does it happen in your agile or not so agile team? When the team is allowed or even requested to synchronize with itself on a daily basis, does it feel like annoying micromanagement? Is your Scrum Master perceived as a directing boss or as a facilitating device for help?

More on the micromanagement by Product Owner and not allowing to focus on the long term later. Stay tuned.

(Photo courtesy of D’Arcy Norman @ flickr)

7 Tips for Improving the Daily Scrum


Daily Scrum also known as daily standup meeting is an important element of the Scrum process. The structure of the meeting is quite rigid and fixed. Everybody has to stand up, meeting should take no longer, than 15 minutes and everybody should answer three questions: “What did you do since the last meeting?”, “What are you going to do until the next meeting?”, “What impedes you from being more productive?”. The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems.

Things to watch during the daily standups are:

1. Standup means stand up, no sitting, really.
Standing up on the daily Scrum draws attention to the brevity of the meeting. The purpose of the meeting is synchronization and no lengthy problem solving. Standing helps to remember that problem solving except the smallest one has to be taken offline – nobody likes to stand for an hour while two guys are arguing about the protocol implementation details.

2. Keep it short. 15 minutes max.

Everybody can spend 15 minutes a day on synchronizing with the others. Especially if it happens to be immediately before or right after the lunch time. Spending half an hour is a very different story. In my experience most of the time the 5-6 person teams are usually done in just 7-10 minutes.

3. Stand in front of the visual progress artifact.
Ideally in front of the task board together with the product and sprint backlog. Visuality and tangibility help discussing things. If task board is used, developers often like waving hands towards the card being currently discussed or even move the cards during this meeting

4. Everybody should be present.
One of the main reasons for meeting live is to utilize as wide communication bandwidth as possible – people are known to communicate more effectively, when meeting live. If particular team member is unable to participate, another person should report on behalf of his/her. If it is impossible for some reason, catch up later.

5. No typing.
Holding a laptop and making notes is power. The one who types immediately starts looking as a manager and often subconsciously starts writing what he thinks was meant, not what team members actually said. If you need notes, take micro-notes by hand.

6. Concentrate on the second and third question, not on the first one.
What’s done is more of a context for the second and third questions. The real point is to figure out what’s blocking the efficient work and who could help it.

7. If team talks too much to ScM, let him not too look at the team.
Daily standup is for synchronizing between the team members, not between Scrum Master and the team. If team members start behaving as they are reporting to Scrum Master, he can start literally looking at another person or even walk away a little. Such small tricks are often able to confirm that daily Scrum is for the team members and not for the Scrum Master.

Daily Scrum is a powerful tool, but as any other tool it is good, when you know what it’s useful for and have some experience in using it. The above seven simple tips can be good starting points or reminders. However, every team knows best how to adjust its standups to serve them better. The important part is the goal, not the method.

Your experience
What feels important in your daily standup?
(Photo courtesy of improve it @ Flickr)

Drift happens

image Over the course of long projects (and some short ones too), the shared understanding of the project, release, or even iteration goals can drift. Different team members remember or interpret project aspects differently over time. This drift can result in producing a final product that doesn’t satisfy your client’s expectations. So how do we counter drift throughout the life of a project? Some say “Write a vision statement and stick it on the wall?”. I’m not a big fan of “statements”. I think people get lost in them, and statements, over time, can be open to interpretation as well.

Short of a unifying statement of sorts, how else can you keep your team synchronized with the goal’s of the project, release or iteration? That’s where the beauty of agile practices comes in. There are several practices which foster a cohesive, shared understanding of the goals: the iteration planning meetings, the iteration review, the retrospectives…but none more than the daily stand-up. I think the daily stand-up helps anchor agile teams to their goals more than anything else. On a daily basis, drift is kept in check by synchronizing the work underway. If teams treat their daily stand-ups more as a synchronization conversation rather than a status report, I think the daily stand up can go a long way towards preventing drift from happening.

Is this your workstation?

Update by the Artem, AgileSoftwareDevelopment.com owner: This advertisement is not affiliated with AgileSoftwareDevelopment.com. Chris decided to publish some of his excellent writings here and I decided to promote one of his offers to the front page.
image Do you have mad ASP.NET, Ajax, Javascript, and CSS skills? Are you a web development guru? If you are, this might be your workstation. Data Transfer Solutions is hiring and we need someone who can do some serious web development. We’re an agile development shop and we’re looking for a web developer that will fit well with our existing Ft. Collins, CO team. Experience with agile development practices and geographic information systems are a plus but are not a prerequisite. If you’re a web developer and you’re looking for a new place to sit, visit www.chrisspagnuolo.com and click on the Contact Chris button to submit your resume.

Scrum Master Vs Project Manager

Scrum Master is specialized in ensuring the scrum process is implemented as intended. He is the one who takes care of the different agile practices to reach the team. Project Manager is the one who takes care of the planning, project deliverables, billing, process, QA, etc…
And now the question for many is can a project survive without the Scrum Master. Its often the case that a traditional project manager takes training as scrum master and he takes the role of a scrum master.

  • In many organizations its often seen that these two roles are exclusively setup and Scrum Master is often an experienced (SCRUM) and certified professional.
  • It is not about Scrum Master Vs Project Manager, but it more about complementing each other’s responsibilities towards the success of project.
  • Some times its not clear about the responsibilities of the Project Manager and Scrum Master. Team often has the confusion about whom to approach for a particular issue.

Do any of your organizations too have this confusion of the Project Manager and Scrum Master?. How do you deal with the confusion?