Category Archives: Agile Delivery

Some confusion around the project manager role


Scrum has some really good points to it but one of its failings is that it doesn’t recognise the role of the project manager.  This in turn creates all sorts of difficulties for Agile teams, especially those that are transforming a large organisation.  To my thinking if we let go of the PM role then who is going to take over governance of the projects?  This is where I think Atern has got it right as it not only recognises the need for the PM role but strongly encourages its use.  However, my experience informs me that often PM’s in the Atern role have a hard time switching their thinking and behaving to be more aligned with the Agile way of working.  However I personally believe that the Atern handbook doesn’t help the plight of the PM in an all new Agile world as some of its direction can be somewhat misleading.  In this article I will explain more, but I am hoping to get hold of one Atern’s luminaries to shed some light for me on some of these differences.

My appreciation for PMs

But first, let me  clear up a few points as in the past I have been accused of “Project-Manager-Bashing” on some of the courses that I deliver.  I have come from a PM background where I have run projects in Waterfall and RUP; I have also coached and consulted PMs on projects running Atern and Scrum.  So I have much empathy (note, not sympathy – that’s way too debilitating to be in any way resourceful) for PMs moving from a mindset and associated behaviours of waterfall to Agile.  During a transition to Agile there is a time where many (not all) PMs will flounder as they grapple with the new behaviours required of an Agile PM and the thinking that supports these behaviours.  The transition required of PMs is IMHO the most stark and contrasted change required for any of the roles on an Agile project or programme.  To this end I believe that PMs need support and challenge, in equal measures, during this transitional period.  This support and challenge is often provided by means of Agile coaching especially adapted for PMs. (You can check out our offering here.)

What is the role of an Agile Project Manager?

In my opinion the Agile project manager (APM) is a mainly externally facing role.  The main goal of the APM is keep the customer happy and satisfied, in this case the business;  if I’m talking in Atern terms here I mean the business visionary and sponsor.    Now there are other high level managerial duties that the PM will carry out such as high-level project planning and scheduling (do note that I did not include estimating here), monitoring progress against the base-lined project plans, removing impediments that are outside of the solution development teams’ scope and so on.

However the Atern handbook does give the following, what I would call misleading, advice (see p40 under responsibilities):

“managing the overall configuration of the project.” mmmm – What is meant by configuration here?  If we are talking the setup of the teams i.e. should we structure the available people into two or three solution development teams in order to deliver, then I firmly believe that this is a job for the team to consider.  Isn’t this what we mean by empowerment? Aren’t Agile teams supposed to be self organising?  I’m not saying that PMs shouldn’t have some input into this because there may be limitations or restrictions that may mean that the teams can’t organise in the way they would optimally like to.

“motivating the teams to meet their objectives.” I don’t think so!  But imagine for a moment if that were true what possible “carrots” or “sticks” would the PM be offering their team.  When I coach PMs I help them understand this one point at the outset: the only way a PM will motivate the team is by seeking to deal with what Herzberg refers to as the Hygiene factors, things like environment issues, bureaucracy and red-tape, an escalation point for relationships with other team members (between departments) and salary & benefits.  (Of course even this last one not many PMs have much control over.)  I’ve had many PMs have most interesting discussions with me on this point and some even go so far as to say that they feel that it is their responsibility for the teams happiness! Good luck with that one, but I feel that this is a topic for a completely different blog post, but maybe you can provide me some answers below as to why this is a completely unrealistic expectation that is placed on the PM?

“coaching the solution development teams when handling difficult situations.” mmmm – again I can interpret this in many ways.  OK if a team member comes to the PM then I would say by all means be a supportive ear or a challenging voice.  But I feel that the PM ought to be building a network of leaders below them through the team leaders.  Often PM will unintentionally build learned helplessness into their teams by being the person who will solve all the teams problems and issues for them.  This is why I have serious reservations about the ab-use of the term “coaching”.  Much of the coaching I have observed is actually mentoring and falls under the banner of telling people what to do; but hey I know that ship has sailed and I’m not going to be able to get the whole Agile community to address the misappropriation of the term Agile Coach, so ’nuff said.  But coaching isn’t a clever or manipulative way of telling people what to do or giving them advice, that is one small part of coaching that is reserved for “emergencies” and is applied with many caveats.

The PM as the “one wring-able neck”?

I have saved the most challenging quote from the Atern handbook for last: “The Project Manager role is responsible for all aspects of the delivery of the solution.” (The highlighting of all is mine.) Ouch!  So are we back to a case of the PM being the one wring-able neck?  If the project fails the PM gets the boot?  I know this might still be the prevailing wisdom within organisations, but it is inherently flawed.  If the PM believes that they will be the one wring-able neck then they are going to act in ways that will be dis-empowering for the team.  Where is their responsibility?  Are they being given permission to fail.  I know this stuff really reads well in the text books just before we pop off to sleep to dream about our projects being in some Disney movie, but in actuality is the environment within which projects are delivered “blame-free” and “safe to make mistakes and learn from them” zones?  This is not the case in all organisations.   If not then this ceases to be a management issue and becomes a leadership issue.  I’ll write some about this in up and coming posts.

Agile Myth: Agile is “JFDI”

Agile Fact: Agile takes discipline …

Many people think that “doing” Agile is easy.  Some people mistakenly believe that Agile has a culture of JFDI (Just F***ing Do It).  The more mature protagonists and practitioners of Agility believe that Agile takes discipline to execute appropriately.

It takes discipline (and often courage) to:

  • Say no to unrealistic timescales;
  • Self-manage and self-organise;
  • Focus consistently on business goals;
  • Deliver on time;
  • Work as a team rather than as solo artists;
  • Never compromise on our quality;
  • Not rush out of the foundations or release planning phase;
  • Dedicate ourselves to continually improve;
  • To work through our differences with other people and disciplines;
  • Collaborate with other disciplines for team goals;
  • Admit to our mistakes and work towards improving them;
  • Stick to the agreed and committed to Sprint or Timebox goal

I’m only just getting warmed up here – in what other ways is Agile a more disciplined approach – i’d love to read your replies below.




The affinity method for estimating stories


Planning poker is quite a popular method for estimating stories, but one of the huge drawbacks on complex projects is that it takes forever, especially if you have over 20 stories.  Here is a step-by-step guide for how I guide teams through a much quicker process for estimating stories.  I have used this method with teams who have over 200 stories and we have completed the estimating session in under two hours.

When to use this method

This type of estimating is most useful at the foundations or release/delivery planning stage.  It is most useful as I have said before when there are 20+ stories to be estimated.


It is important that before you start the estimating session that the team understands what the story means.  The estimating session will have been preceded by a number of story writing workshops where the stories were discussed with the team members, but not necessarily in great detail.  So completed story cards with preliminary discussions as well as preliminary or high-level acceptance criteria feed into this process.

Clear floor space or wall space 2-5 metres is preferable

Some cautionary notes …

If your team is new to Agile you may find “observers” turning up to the session.  These may be business analysts, product owners, project managers or whatever.  I sometimes find that these people, with best intentions, want to influence the outcome.  For instance project managers are keen to please their sponsors and want to provide estimates that are often smaller than the team feels comfortable with.  When I facilitate these sessions I make the rule that the observers may only do just that- observe.  The only people allowed to estimate are the ones who will be doing the work.  Yes, OK they may get the estimate “wrong” – in fact I can almost guarantee that they will, but the team should be encouraged to learn from their mistakes and not be held hostage to the opinions of others who will not be as committed as the team will be to getting the work done.  To this end I always recommend that the session is facilitated by an experienced Agile mentor or coach who is able to deal with the difficult characters who may unintentionally (or even sometimes intentionally) sabotage the efforts and outcomes of the team before the work has even started.

The Process

Setting up the workspace

1) The far right of the workspace indicates those stories that are the most complex or most time consuming.  The far left indicates those that are the most simple or quickest stories to complete.  I like to put markers on the board to remind people of two sides of this continuum.


2) One member of the team randomly chooses a story card from the pile of stories; they read out the story to the rest of the team.  They then place that story on the board according to how they feel about the level of complexity or time to complete.

3) The next team member then randomly selects the next story and places it either to the right or the left or in the same relative position to the previous story.  A long way to the right of the previous story suggests a very much more complex story, while one a long way to the left would indicate a much simpler or easier story to complete.  The is a relative estimating method so the distance between the stories is important.

4) This continues for a few goes until there is about five or six stories on the board.

5) Once there are a number of stories on the board team members then have a choice in how to use their turn

            a) they can either select another story and place it on the board or;

            b) they can move one of the other stories.

In the instance where the member elects to move a story they explain to the rest of the team why they believe this to be so.  The team can then discuss where is the most appropriate place for the story.  I find that it is good to keep the discussion short and if there is serious disagreement in the team then err on the side of caution and put the story further to the right.

6) The process continues until all the stories are on the board.

7) Assigning the points

The outcome should now be groups of stories spread across the board.  We then allocate story points according to the rough Fibonacci sequence as we do in planning poker – (1, 2, 3, 5, 8, 13, 20, 40 & 100) – we then write the story point value on each of the cards.

Again it is important to not get too hung up on the numbers at this stage of the estimating process as finer turned estimates will be provided as the project progresses and more is known about the product we are creating.  A good point to remember is that it is better to be roughly right rather than precisely wrong especially in the early stages of the project. However it is worthwhile just retesting our thinking with some of those stories that may have been borderline between two groups, especially those of numerical significance i.e. those the are between 20 and 40 or 40 and 100.  There is no point in “dying in a ditch” over a story is a 1 or a 2 at this point.

If you have any further questions about this technique then please feel free to ask in the meantime … happy estimating 🙂

The 3 Cs of User Stories

In our consulting work we often refer to the three C’s of user stories, here is what we mean.  The C’s are abbreviations for the:

  • Card
  • Conversation
  • Confirmation

The card contains little information and is often written in the form “As A <<Role Name>> I want <<a feature>> so that <<some value delivered>>”.  There are many different forms that this can take, but what is most important is that what is written, is meaningful to the team delivering the feature and the customer (or product owner) requesting it. Developers cannot write software from the card alone and to that end they need the next part … the conversation.

The conversation is the essence of the requirement and conversations can spawn many outputs or artefacts such as models, notes, story maps or even good old fashioned code!  I like to think of the conversation as the most important part of the story because this is where the learning is achieved.

For years as a systems or business analyst I used to write requirements specifications that could sink a small boat and then lob these over the partition to my design colleagues (god I hated conversations with designers – they asked way too many questions ;0) ).  But seriously, minimising the written word to specify requirements is important, but you maybe can’t get away with eliminating it altogether.

Conversations, and more importantly evolving conversations, allow the developer/designer to hold the concepts of the requirement in their head while the design and code become the output of a requirements conversation rather than some weighty tome.  This minimises ambiguity and uncertainty as the analyst, or better yet customer, can see their thoughts become manifest as a result of a few insightful conversations.  Changes can then be made directly as the feedback is received rather than going through some lengthy change management process which will result in a document being changed giving the risk of more ambiguity.

The confirmation (often written on the back of the story card) gives us the high-level criteria against which the resulting feature will be tested against.  I like the idea of specifying the system by examples of what the system will do both when it functions correctly or incorrectly.  This is a better way of creating a specification as opposed to my boat sinking documentation of yore. Alternatively simple closed questions such as “does the screen go black?” may well suffice for acceptance criteria.  But these in themselves will not be the complete set of acceptance tests but only a high level set of tests to give the customer or product owner confidence that the feature that has been created fulfils their criteria of a working feature.

The 12 Agile Principles for Software Development

Here is a reminder of the 12 Agile principles for software development.  These have been recreated here for your convenience.  It you would like to go straight to the origin of these principles then please click here.  And yes I have corrected the americanised spelling 🙂

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Scrum Ceremonies: Sprint Review

Definition of the sprint review


The sprint review is held at the end of every sprint.  This where the team demonstrate the next increment of the product to be delivered.  The meeting is intentionally kept short and informal as the formalised part of  the review will have already taken place.  The way in which the meeting works best is to run the sprint review as a product demo where the new features that have been added during this iteration are presented to the audience.

Participants in the sprint review

The audience at the sprint review can be anybody who is interested in the latest developments to the product as well as the team.  I suggest that all the team are present and will explain why in a short while.

Preparation for the sprint review

I often advise teams not to spend hours and hours preparing for the sprint review, however it is always good to make sure that it goes according to plan; so it’s really a question of doing enough prep for the meeting to make sure everything runs smoothly.  I have sat in on some of the most embarrassing sprint reviews when senior management have been in attendance (isn’t it funny how it all goes wrong then);  the team have had a most successful sprint and then they get bad PR when the overhead projector or some other technical aspect of the demo doesn’t work.  So a tip, that seems so obvious so I ask myself why bother saying it, but turn up 10 minutes before the suggested start time and have a quick run through just to be certain of success.

Running the sprint review

So everyone is set up and you’re ready to go … I find that it is always useful to spent the first two minutes of the sprint review reminding (or informing because maybe everybody wasn’t aware) everybody of  what the sprint goal was; which part of the goals you achieved and thus what will be demonstrated in the sprint review today.  I often suggest that it is the Product Owner who gives this introduction, which is contrary to what Schwaber and Beedle suggest (they suggest the scrum master coordinates and conducts the review – Schwaber and Beedle, 2002, Agile Software Development with Scrum, Pearson education, p55) I’m happy to explain my reasoning behind this slight twist if anyone is interested.  This nicely sets the scene and give a professional feel about the sprint review.  Informal shouldn’t translate as unprofessional.

I always suggest that the Product Owner requests that if anyone has any questions to wait until the end of the demo.  If necessary the team can rerun the demo in order to address any key points or questions raised.  Of course this is optional and it may be easier for the teams to answer questions as they go, because there might be a lot to set up in order to rerun the demo; the Product Owner should explicitly state that preference at the start of the meeting.  This is because often visitors might feel that it is being rude to interrupt the flow, and sometimes it is, but if the rules and boundaries are set at the start of the meeting then usually all will fall into place.

So once the scene has been set the Product Owner can hand over to the team for the demo.

It is important to note that we only cover what has been completed and has been agreed by the Product Owner to have met the required quality standard for the product.  Anything that hasn’t been completed or “signed off” is not demonstrated.  Which leads me nicely onto the real purpose of the sprint review.

The real purpose of the sprint review …

I see that there are two reasons for the sprint review.  Firstly it offers the attendees the chance to understand and see for themselves the progress that has been made on the product.  It might be necessary for the Product Owner to discuss where this fits into the overall scope of the product delivery in the introduction at the start of the meeting.

Secondly the sprint review offers the team a chance to bring closure to their work for the  duration of the sprint.  The items or features that are demonstrated are considered to be closed and thus any outstanding requirements or other associated documentation is considered to also be closed.  This gives the team an opportunity to celebrate their success on meeting their goals and it is an opportunity for any senior management present to recognise and affirm the efforts of the team.  This is why I said earlier that it is important for all team members to be present; everyone needs to feel that sense of closure and completeness for the work carried out in the previous iteration.  Equally so, everyone deserves to share in the recognition of the work done to date.

What a sprint review is not …

      • It is not a meeting designed to critise or for the team to take further actions for improvement to the product. It should be noted that this meeting is an informational meeting that raises awareness of the goals achieved thus far   These are channelled through the product owner in the subsequent requirements gathering phase.  Therefore it is not a Go – No-Go meeting.  If the product is not considered fit for purpose before the review then my advise is to cancel the sprint review; the product owner can inform the necessary stakeholders as to why the product was considered to not meet the teams definition of done.
      • It is not death by PowerPoint.  I don’t like to be too directive on this point because PowerPoint does have its place; but the main focus should be on the demoing the product itself.  This is not always possible and some other means of demonstrating progress can be creatively considered without the use of PowerPoint.
      • It is not a document review meeting.  Documents are often a necessary output from the product development process.  If a document has been created it should be quality assured before the meeting and the smallest of introductions to identify where the document is stored and that it has been formally signed off according to the previously agreed definition of done.

Do you have any other tips for my other readers?

If you have any tips on how to run a successful sprint review then please submit them in the comment box below.  I will also give a link back to your site in return.  Thanks.



Something Agile Leaders can learn from Steve Jobs

Ok – maybe there are lots of things that Agile Leaders can learn from the  late Steve Jobs, but here is just one particular example.

Focus to bring business value …

Steve JobsIt is reported that when he returned to Apple in 1997 Steve Jobs reduced the number of Apple products from 350 down to just 10.  Why did he do this?  Surely a company would have more chance of penetrating the market with over three hundred products rather than just 10. Well, no.

One of the main values of Scrum is focus.  The creators of Scrum understood that there is only a certain amount of meaningful attention that an individual or a team can apply to a problem in any given time, otherwise the level of noise in the team just increases.  The same is true for organisations also where the cost of maintaining a product or service continues to demand attention long after the product has been created and delivered.

Focus as a cornerstone value for Agile business practice

One of the important things a leader must do in their organisation is to continue to critically appraise which products they want their teams to work on.  I was asked to by a senior manager in an organisation to sit in on their weekly review board and provide some Agile consulting to her and the other attendees.  I made an observation about the number of change projects that they had ongoing.  There were over fifty projects of varying sizes and complexity.  Her comment back to me was “well that’s what’s expected to be done around here”.  We had some more discussions on this point but in short the organisation continues to fail to meet all of its targets and is continually playing catch up on meeting its commitments with its clients.

Why wont leaders change?

There is a fear that prevails in many senior managers that they must be seen to be doing more, yet they will have heard the expression “less is more” but they will continue to respond to their fears rather than the needs of their customers. Customers may not often want more, but they do want quality.  This is why Apple excelled at what they did.  (I use the past tense because I’m sure there are many like me who are waiting to see if the Apple culture of creativity and quality will continue in the absence of one of the most inspired leaders the world has known.)

The solution …

Prioritise.  Again experience informs me that is an often uncomfortable conversation I have with senior managers who believe they want it all and they need it now.  I explain about focus and attention; I talk about sustained pace of the team; I implore on the basis of better quality and motivated teams;  but the justification that I am given is that they don’t want to fall behind the competition; or certain stakeholders will expect these features or changes or some other form of rationalisation that make their demands right.

In short by asking a senior manager to prioritise  I am asking them to take more time to think about where their priorities lie and as a result what they should focus on. But all too often it is easier to to put more pressure on the product delivery teams to deliver more and quicker.  This keeps the managers from making painful choices and having uncomfortable conversations that involve saying no to stakeholders.  This is not leading but passing the buck and the consequence of these types of decisions that put more pressure on the delivery teams is poor quality and as a result poor customer satisfaction.


It makes me wonder what would have happen if Steve Jobs would have allowed his executive team to continue working on over 300 different products.  Would we have ever seen the ipod, ipad, iphone or itunes? And if we did would we have seen lesser versions of these products that would have annoyed us?  In short there is much business sense in focusing our resources on doing a few things well rather than a lot things mediocre. Remember less really is more.

About the Author

Mark Buchan is an Agile consultant  with experience of delivering organisational transformation for his clients.  He has worked with organisations such as Rolls-Royce, Nokia, Bupa and BT.

You can view Mark’s profile on linked-in

You can also follow him on twitter

On Time, On Budget, Happy Customer

When I first came up with the idea of this website I thought it might be rather hypocritical of me to look at its delivery as anything other than Agile.  So I looked at the “Iron Triangle” of time, cost and features and decided that my budget and time were the two elements to remain fixed while I flexed on the features delivered.


To my mind the core of Agility is the ability to flex the requirements in the face of changing environments (both internal and external).  This doesn’t mean that I wont get the features I want – ever.  No; what it means is that I prioritise what’s important to me up front and make a decision to focus on the features that deliver most business value.  This is a common misconception about Agile delivery; business think that unless they prioritise everything in the product as a “must have” requirement, then they wont get it at all.  The reality is we focus on fewer items in the short term to order to deliver the right thing for our customer.  We can then successively or incrementally add those set of features in future releases of our product.

Delivering Business Value

A key question that was important for me to address as the Product Owner of my website was “what delivers greatest value?”.  In the past I had convinced myself that sexy websites with all the bells and whistles were what would sell the services that I offered.  Wrong! As I have become to understand my market a little better I have learned that there is no value for my customer in an attractive website that tells them how brilliant I am.  What actually delivers value for my clients is providing information or content that can help them make more meaningful decisions or improve their business or personal performance in some small way.  Yes usability is important, but that is something that I can improve over time with enough feedback from the marketplace.  Again my experience informs me that my customers value content quality content over sexy graphics.

Lessons learned?

Now can I honestly say that I became enlightened overnight? No; I have made many mistakes overtime and repeated some of them because I wanted to be sure they were mistakes in the first place.  And who knows: maybe this latest product in my evolution will also tank, but at least this time I know I have done something different and changed my behaviours and attitudes in the meantime.  For this at least I can feel satisfied and continue to be informed by reality rather than my own biases and patterns.