The Lieutenant Commander ran and experiment to test the doctrine of the Commander’s Intent.  The iterative approach to decision making and high levels of communication were highlighted in the article.

“Successful company commanders that matched their battalion commander’s intent initially determined the disposition of friendly and enemy forces.  They specifically referenced procedures and the intent statement in the battalion OPORD.  They also acknowledged that they had to coordinate their activities with commanders of adjacent units prior to taking any action”

I’m going to extrapolate this finding to say that it is also needed to run a successful project.  There are two parts to this paragraph – follow the intent and work with others to achieve your goal.  Although neither of these two items are listed in the Manifesto for Agile Software Development, it’s pretty obvious that if you ignore these then you’re not very likely to run a successful project.

Iterate to continually improve

The paper highlights what makes certain commanders unsuccessful including:

• Did not refer to the battalion commander’s statement of intent.
• Exhibited flawed tactical knowledge
• Rigid adherence to procedures despite new information that indicated they were facing a novel, unanticipated situation.

Which I’ll translate as:

• Did not clarify that the goal they were working towards was the actual goal
• Did not have the technical knowledge to build the software
• Did not adjust the plan when new information changed the situation

Points two and three have obvious consequence to agile teams.  Point two refers to issues with technical abilities and one of the agile manifesto’s principles is “Continuous attention to technical excellence and good design enhances agility.”  At the ten year retrospective of the signing of the Agile Manifesto the number one success factor of agile teams was demanding technical excellence.

Point three is embedded right into the heart of Manifesto for Agile Software Development – we have come to value “Responding to change over following a plan“.  Iterate.

How do we help teams to work better?

We need to spend more time communicating intent.  Both managers and their teams need a shared understanding of a projects goals and intentions.  It’s too easy to say “build widget X” when instead, as leaders, we should be explaining the issue widget X is attempting to solve.  Understanding the rationale behind these decisions aligns teams and also teaches your team how see a problem and solve it in the same way you would, making them more likely to be self sustaining.

Investment in technical skills and prioritizing technical excellence is also critical to succeeding in software development.  It’s a tough one as software professionals have been incorrectly (incorrectly) depicted as a commodity over the past ten year.  Good people are hard to find, especially in highly technical areas and we cannot to treat them as disposable items.

Finally, we need to continually revisit the plan.  Teams need to look up at the horizon with their leadership teams and make sure they are properly aligned.

We’d love to hear your thoughts and comments.

The Commander’s Intent, the Agile philosophy and New Product Development approaches share a lot in common.  At their heart they embrace that a highly complex and uncertain environment requires decision making to be distributed to the team so that teams can dynamically adapt to new situations.  In old fashioned management speak we’d call this delegation and delegation requires trust.

You'd trust these guys, right!?

Lieutenant Colonel Lawrence G. Shattuck, US Army in his paper “Communicating Intent and Imparting Presence” discusses the doctrine the Commander’s Intent. In it he states:

“confidence in subordinates stems from the superior’s intimate personal knowledge of each one.”

Futhermore:

“Trust between superior and subordinate is the cornerstone of mission-oriented command.  The superior trusts his subordinate to exercise his judgment and creativity, to act as the situation dictates to reach the maximum goal articulated in his mission; the subordinate trusts that whatever action he takes in good faith to contribute to the good of the whole will be supported by his superior.”

In a software delivery context I could read this as “Get to know your team, let them do their jobs and trust that they want the best outcome.”

When I read the Manifesto for Agile Software Development I see it as a worldview based on trust.  Three of the four points listed revolve around trust.

In my followup article I’ll discuss how the Commander’s Intent proves that Big Upfront Design hindered successful outcomes.

Please take the time to read the full paper.

I was fortunate enough to rack up enough votes to speak on whether “Agile Software Development Prevent Rounded Products.”  I’ve attached the slides below but please go to the slideshare site and turn on the notes, that is where lot of the good bits are.

I also want to say thanks to Mishymash, who was attentive enough to take some great notes of my session too in mind map form (they look great, please check them out).

Product Camp (or PCamp for those in the know) Sydney is being held on the 4th of June at the Brainmates offices and provides a place for product professionals to share their knowledge.  In the Agile world we work with product manager in various guises – sometimes directly and sometimes through a conduit.  In a small company your Product Manager may be the CEO or head of marketing.  If you’re in a larger company you may get access to your product manager via a product owner (if you adhere to Scrum stylings), producer or a very dynamic BA.

We like the fact that all parts of the product management spectrum attend, share their knowledge, learn what works well for them and ask other participants to help them on their journey.  This is the essence of product camp – participants helping each other.  It’s great fun, with a great group of people.

Agile Bench is very proud to help sponsor PCamp Sydney.  We hope to see you there.  Please say hi!

The value of a plan is that it provides a focal point in which to make decisions as well as setting expectations on the value to be delivered. From a plan we can see how long a project is projected to take or what the project is expected to deliver given a set of assumptions.

Good planning – agile planning – expects and even welcomes change as new information is discovered. In agile projects we expect to learn more about what our stakeholders want during the project. In agile projects we want to take the new learning and change our plan to reflect this new information. When we discover new information we can:

1. ignore it – defer acting on the information because our stakeholders do not feel the new information is important enough to act on.
2. swap it – turn the new learning into stories, have them estimated by the delivery team and have the stakeholder swap these stories for other stories of equivalent cost. Ideally this would only be done if the new stories were of greater value than the stories they are replacing.
3. add more people – more money – add more people to deliver these new stories. Adding more people can definitely help a project deliver more quickly. The downside of this is that adding people does not linearly increase your ability to deliver and at some stage will actually slow you down. Fred Brook’s The Mythical Man-Month: Essays on Software Engineering is the classic work in this area. Or put another way, you can’t make a baby in one month with nine women.
4. add more time – more money – How important is the end date?
5. increase output – smarter – up skill your current team or replace some of your team with better performers. Some people deliver more than others – for a myriad of reasons. I prefer to work with fewer smart people than many mediocre ones and I believe it gives you better results in a shorter time.
6. increase output – harder – get your team to work longer hours to deliver your newfound scope. It’s a classic. You may be able to do this with little to no damage in the short term but in the long term this approach will definitely bite you hard.
7. reduce cost – you may be able to find others who are willing to do the same work at the same quality for a cheaper price. Can you find an enthusiastic graduate? Can you outsource a part of your project? Can you hire that person looking for a break who is enthusiastic? There are no guarantees with this strategy, and you’ll probably spend more management time on it (so it isn’t free) but it can work well.

These are a few of the strategies we’ve used. What others have you tried that have worked well?

Bugs, errors, flaws, mistakes, failures, issues or faults. If your team is developing software then not everything the team makes will be perfect first time. “To err is human” as Alexander Pope said. But what is a good agile team to do?

Let’s start by defining what a software bug is, then work out what to do. A software bug is found when the system doesn’t work the in the way it was specified. That’s fairly straightforward.

It is also important to define what a software bug is not. You have not found a software bug if the system doesn’t work in the way you want it to, but that behaviour was not specified. Let’s dig into this a bit.

Let’s say you’ve gone the full nine yards and created a well-defined story, with measureable acceptance criteria and your team has tested their code. Let’s say you have development specialist and testing specialist like in most mid to large organisations. If the programmers believe they’ve completed development work but the testers disagree then you’ve got to work out what to do next. The first thing to do is to get the programmers and the testers to spend some time together getting to the bottom of issue – if you can face-to-face or over the phone. When programmers and the testers agree that the intention of the story, which was very focused, was not met then we would consider this card as “not done” and given back to the programmers to continue working on with a clearer requirements to work to. If you can’t get them to agree bring in the business analysts or product owners to help get to the bottom of the issue. Yes, the software isn’t working, but there is no value in raising a software bug.

“No Value!” I hear you cry.

Raising a software bug only adds value if you need to track and prioritise the work. Raising a software bug at this point is to raise a bug on work that is not done. Yep, that story is still a work in progress and to spin off a separate card is just overhead that isn’t needed. Instead, with your teams newly gained understanding of the problem domain, note the fault, get the programmers to write a test that repeats the issue and continue working on the story until it is “done”. Different teams have different definitions for “done”, but for the sake of argument let’s say it is when your project owner says that the work is complete and there is nothing else to be done for the item to go live.

The other common case is when a product owner, once seeing a story in it’s near complete stage, will realise that it doesn’t do all the things they want it to. This is also not a bug. If the modifications are small and help complete the intended story then change the acceptance criteria, re-evaluate the estimate and get the work done. If you’ve identified a new piece of work, then spin off a separate story with it’s own acceptance criteria and estimate. This way the newly discovered scope can be investigated properly, prioritized, discussed and communicated out.

If your product owner has signed off the story and a new issue is found, then we do one of two things. If the issue is part of the current iteration and it’s small then move the card back into “to-do” column and just get it done. If the issue is big or is found in a subsequent iteration we write it up as it’s own card and prioritise it against the rest of the features.

Each team needs to find it’s own groove and this approach works well in many teams that I’ve run.

We can boil this down to a simple rule: you can’t have software bugs on work that isn’t finished. Oh, and Mr Pope’s full statement is “To err is human, to forgive is divine.”

A very common stand-up anti-pattern has each member of the team talk about tasks they performed rather than their achievements. I’m going to list some common task oriented items and make suggestions on how they could be better phrased.

Stand Up by KarthicC

“I went to a meeting”

This is a pretty common generalization that simply requires rephrasing to talk about the achievements gained from the meeting (you did have a meeting with outcomes, right!?). For instance, instead of “we had a meeting” we could say “the ABC team’s timelines have changed which will have an impact on our timelines, we haven’t worked through the details but we believe we’ll be delayed on integrating widget X by 3 weeks”. Now everyone on the team understands what you learned from “the meeting.”

“I wrote some tests”

It’s great that tests were written, but this doesn’t tell the team the value of your actions (especially if I’m a non-technical member of the team). This could alternatively be said as “In our rush to get Widget X out the door to reach milestone 1 we deliberately didn’t test Widget X as thoroughly as we need to – we wore the risk. Yesterday we spent time adding in those tests so that we don’t have regression errors as we continue to work on Widget X in the future.” It’s simple, and perhaps obvious to the technical folk, but this level of conversation will ensure all stakeholders understand the value of you and your work.

“I can’t remember”

Coming to a meeting unprepared just wastes everyone’s time.  A quick review, prior to stand-up, of  your previous work should give you more to say. Easy!

“Today I’ll be cleaning out my inbox”

This type of sentence is uttered because team members either want to reassure the team that they are actually doing work or because they haven’t spent the time to collect their thoughts before the meeting. If you haven’t collected your thoughts, then just spend a minute or two getting your head in gear so that you use everyone else’s time valuably – this should be easy to solve.

If, on the other hand, you are trying to reassure the team that you are doing “stuff”, then stop.

All teams need lots of trust to be truly high performing. Your manager should value your work and have some understanding of what you are doing. If you are “cleaning out your inbox” because you’ve just come back from vacation, then who am I to argue, but the rest of the team doesn’t need to know about it. Please just say “pass” or “nothing to add”.

Talking about work you’ve done that isn’t related to the project the stand-up is concerned about.

This is related to the previous point, and again it is either about trust or wanting to show your peers that you are working. See above.

Have you see these anti-patterns? Are there others that get your goat? Could you add them to the comments below for other readers to learn from.

Image “the first standup” by karthicc

Here is the good news! We are opening up our API and we are very excited about it.

The new API give you programmatic access to Iterations, Stories and Comments for your project. We’ve worked hard at putting together high quality documentation. I’ll put out a few examples here to highlight how the API works.

All methods require authentication before we’ll hand over your precious data (we very much care about the privacy and safety of your data). We provide authentication via a token which must be supplied in the HTTP request. You can find your token on the account setting page.

Projects

Available methods:

• Get all project for the current user
• Get a single project for the current user

When a project is requested basic information such as the iteration sizes and title are returned. Also included in the returned payload is a list of users who are members of the project.

e.g. curl -H "X-AgileBench-Token: TOKEN" -H "Content-type: application/json" http://agilebench.local/api/v1/projects/477

{
    "confidence_tolerance": 20,
    "created_at": "2010-04-05T00:00:00Z",
    "estimate_values": "1,2,3,5,8,unestimated",
    "id": 477,
    "iteration_size_unit": "week",
    "iteration_start_day": "Monday",
    "iteration_unit": 2,
    "title": "Art Social Networking Site (DEMO)",
    "uri": "/projects/477-art-social-networking-site-demo",
    "users": [
        {
            "id": 6704,
            "login": "max",
            "role": "Owner",
            "state": "active",
            "uri": "/projects/477-art-social-networking-site-demo/users/6704"
        },
        {
            "id": 6705,
            "login": "kit",
            "role": "Collaborator",
            "state": "active",
            "uri": "/projects/477-art-social-networking-site-demo/users/6705"
        },
        {
            "id": 6706,
            "login": "sidney",
            "role": "Collaborator",
            "state": "active",
            "uri": "/projects/477-art-social-networking-site-demo/users/6706"
        }
    ],
    "velocity": 13
}

Iterations

Available methods:

• Get an iteration (standard iteration, current iteration or backlog)
• Get all iterations for a project

Let’s say you would like to get a list of stories in your backlog.
e.g.
curl -H "X-AgileBench-Token: TOKEN" -H "Content-type: application/json" http://agilebench.local/api/v1/projects/{project_id}/backlog

Which will return the backlog and the stories within the backlog:

{
    "id": 1324,
    "position": 1,
    "project_id": 477,
    "stories": [
        {
            "blocked": false,
            "comments_count": 0,
            "created_at": "2010-06-14T00:00:00Z",
            "estimate": "5 points",
            "label": 44,
            "position": 1,
            "story_type": "story",
            "title": "As a site owner I want to charge users for an account",
            "updated_at": "2010-06-14T00:00:00Z",
            "uri": "http://agilebench.local/projects/477-art-social-networking-site-demo/stories/44",
            "workflow_state": "todo"
        },
        ...
    ],
    "title": "Backlog",
    "uri": "http://agilebench.local/projects/477-art-social-networking-site-demo/backlog",
    "workflow_state": "todo"
}

Stories

Available methods:

• Get a story
• Get all stories for an iteration
• Update a story

Let’s say you would like to update a story
e.g.
curl -X PUT -H "X-AgileBench-Token: TOKEN" -H "Content-type: application/json" http://agilebench.local/api/v1/projects/{project_id}/stories/{story_id} -d '{"estimate":"1 point","workflow_state":"in_progress"}'

Which will return the updated story:

{
    "blocked": false,
    "comments_count": 0,
    "created_at": "2010-06-14T00:00:00Z",
    "estimate": "1 point",
    "label": 15,
    "position": 1,
    "story_type": "story",
    "title": "As a site owner I want to create a blog",
    "updated_at": "2010-10-25T20:09:07Z",
    "uri": "http://agilebench.local/projects/477-art-social-networking-site-demo/stories/15",
    "workflow_state": "in_progress"
}

There are a couple of differences here from the backlog request we showed before. Firstly we’ve had to specify the PUT HTTP verb to signify we are updating a resource. We also have to provide the data required to update the story, in this case we’re updating the estimate and we’re transitioning the story to being “in progress” from todo. A list of the attributes that can be updated can be found in the “API docs”|http://agilebench.com/api/.

It’s also worth noting that stories don’t have an id, they have a label as their primary key (which is namespaced by the project id).

Comments

Available methods:

• Get all comments for an story
• Create a new comment

Let’s say you would like to create a comment on a story
e.g.
curl -X POST -H "X-AgileBench-Token: TOKEN" -H "Content-type: application/json" http://agilebench.local/api/v1/projects/{project_id}/stories/{story_id}/comments -d '{"text": "Here is my comment"}'

Which will return the newly created comment:

{
    "id": 442,
    "text": "Here is my comment",
    "user": {
        "display_name": "Max Bench",
        "uri": "/projects/477-art-social-networking-site-demo/users/6704"
    }
}

We are already using this internally for source code callbacks into Agile Bench.

Why we’re publishing these APIs

We know there are a lot more ideas and energy outside of the Agile Bench walls than inside it. We want to open up our platform and let others make beautiful things happen.

We have more in store. We also would love your feedback and look forward to more API goodness.

So what should you do, do you hand off your other responsibilities to the marketing team or do you bring in someone to work full time on product development. From our point of view it depends on where you are in the product lifecycle, how your organisation is set up and what your strategic priorities are.

The folks over at Pragmatic Marketing talk about 2 different types of roles. A product owner (a scrum term) who sits within the agile development team and defines requirements, removes roadblocks and researches new functions and a product manager who sits outside of the development team but who has ultimate responsibility for the product being brought into the market place. In some cases they feel the 2 roles can be covered by an experienced agile product manager and in other cases they are split.

If you do take on the role, agile product management is not for the faint hearted. You may not be used to being so close to the development team, delivering your product in an iterative manner or not fully knowing what will be delivered until it is, but don’t worry you’ll get there in the end and it always helps to have some one around who’s been through it before. Some of the pitfalls to avoid include being tempted to change requirements or drop in new features during an iteration, spending too long documenting features or not planning what you want to deliver a couple of iterations ahead remember of course your plan may change.

In the end, agile won’t solve all of your problems. You still need to get out there, talk to your customers and shape the information you gather into something that your team can deliver. What it should do though is bring you closer to your product sooner than you would have normally been, which hopefully means you don’t get that confused feeling at the end of a project where you wonder why on earth the team built what they did.

Here are few articles, presentations and books we have come across that should help you out:

• http://theagileproductmanager.blogspot.com/2008/07/going-agile-consider-this.html
• http://www.slideshare.net/Enthiosys/agile2009-product-managerproduct-owner-dilemma?src=embed
• http://www.pragmaticmarketing.com/pdf/Living_in_an_Agile_World.pdf
• http://www.enthiosys.com/insights-tools/a09-recap/
• http://www.pragmaticmarketing.com/publications/magazine/4/4/0608bn
• The Art of Product Management
• http://crankypm.com/2007/04/so-you-think-agile-methodologies-exempt-you-from-product-management/
• http://onproductmanagement.net/2008/04/29/agiledev_and_pm/

The typical view of agile is that its all about hacking the code, no documentation and developers going off and doing their own thing, whereas with UX and User Centred Design (UCD) in particular the view is that it all takes too long, the design has to be perfect, we have to check with all of these users and we could have built and launched it by now…

The key issue seems to be how do you fit some of the fundamental UX methods into the small iterations that Agile develop teams work. A lot of teams run parallel design and build iterations, so that the design team has the time to create concepts and test them before handing them over to be built. This approach works but doesn’t really fit in with the agile principles of a team working together on discreet pieces of functionality within the same iteration

Another way to bring the teams together is to extend the scope of iteration 0 by not only looking at planning but also defining a high level information architecture, because changing this halfway through a project is very painful. We are not talking about Big Design Up Front (BDUF) but just enough so that you can understand how the product fits together.

In the end we think it comes down to the people more than the process, if the team wants to make it work they will find a way, just as the Agile Manifesto says it should.

We don’t think we have the perfect answer and there are lots of resources out on the web on this subject, below is a list of links to other articles, presentations and blog posts that we’ve read along the way.

• www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html
• http://www.slideshare.net/LaneHalley/making-sense-of-ucd-and-agile
• http://msdn.microsoft.com/en-us/magazine/dd882523.aspx
• www.thinkingandmaking.com/view/agile-ux-six
• http://www.slideshare.net/kghosh71/agile-and-ux-can-they-be-married
• http://www.slideshare.net/usabilitycounts/agile-and-ux-july-8-scrum-club-los-angeles-ca
• http://www.adaptivepath.com/blog/2009/02/03/burndowns-and-flareups-in-agile-design/
• http://www.slideshare.net/Cennydd/getting-real-about-agile-design-arial
• http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&ac=384
• http://www.disambiguity.com/waterfall-bad-washing-machine-good-ia-summit-07-slides/
• http://upassoc.org/upa_publications/jus/2007may/agile-ucd.pdf