The Company with No Arse

I want to work for a company with no arse – that means that there’s nothing to cover and nothing to kiss (or blow smoke up)!

This thought occurred to me today in a large workshop aimed at identifying the cultural elements of “world class” companies. Never being one to shy away from a simplistic way to express what is actually a complex set of qualities I thought that this expression captured much of the feeling of the day. In a room full of very smart people I was very pleasantly surprised to see ego cast adrift and humble self-reflection take center stage. This kind of thinking could very well engender a “world class” culture. At the very least it could provide the space for such a culture to grow into.

Of course the things that get in the way of such a culture are many, and more of them come from the very people striving within the culture than we might first realise. Our own thinking and patterns probably limit us much more than any external pressure. The biggest lesson that I have taken away from today is just how we can all learn if we are open to it. Learning is just the first step though. Taking action, and backing it up, reflecting on it, adjusting it, and then repeating this cycle endlessly is going to be the real challenge…

Agile Team Leader or Project Manager?

A recent post on infoq has prompted this follow up. There are many folk who believe in the ideal of a self managing team – one that follows Agile practices rigorously and delivers a constant stream of benefit to the business. I’m not one of those people. I believe that a certain amount of specialisation leads to people having a higher sense of responsibility for what they do. If it is always the team that decides, and always the team that succeeds or fails then the role of the individual is diminished.

There will always be people on teams who need some form of individual recognition or responsibility to perform at their best. This is especially true of larger teams where many different personalities make up the mix – it may be possible to get a small group of people to truly work together but it is much harder to do when more people are involved. A team’s culture or set of ethics become diluted with each new person that comes on board.

When Agile projects fail it is often because the team has lost touch with broader business needs, or acts “inwardly”. They may be being efficient and they may be improving internal efficiency but this will eventually come unstuck unless someone is paying attention to, and actively fostering, the macro or external view. To do this effectively, someone needs to be “responsible” for it. The team may well cope for a time, and indeed if the team is made up of extremely experienced, articulate, broad-minded individuals then they may well handle many “external” situations that arise. Most teams, however, are made up of people with a variety of skills, specialisations and experience. People are chosen for their expertise.

It’s true that an Agile project manager should not make all the decisions. They should not “command and control” the day to day running of the project. Agile gives us a very good, very empowering set of tools that allow the team to do this themselves. Agile does not always give us a good set of tools for dealing with vagaries and political to-ing and fro-ing. Logic is not always the answer.

In his post on infoq, Mike Bria provides a summary of Patrick Wilson-Welsh’s post on this subject. His summary of the characteristics of the “new leadership” is as follows (and I’m reproducing it because I like it a lot and think it should be circulated):

• Continuous Leadership
  Understanding the team’s place in the organization’s goals, being a single point of leadership (for the team) and accountability (to stakeholders), building a “safe container” for the team to work within, growing trust and respect between team and stakeholders, and continuously improving team cohesion.
• Continuous Planning
  Ensuring the team become increasing capable of meeting their own established commitments, ensuring everything remain “big and visible”, manages metrics, making “the plan the bad guy” (as opposed to the people), and ensuring the “plan changes with demand/supply”.
• Continuous Execution
  “Monitoring/managing team velocity/throughput”, securing resources, removing and escalating blockages. Ultimately, “keeping flow, momentum and focus in the team”.
• Continuous Risk Reduction
  Identifying risks and making their “potential impacts big and visible to the right people”, ensuring risk reduction occurs, and quantifying risk management effectiveness.
• Continuous Improvement (Agile Coaching)
  Driving the “improvement of the overall Definition of Done”, sensing and drawing attention to performance breakdowns, facilitating team improvements in the right areas, and helping the team learn emerging practices from outside itself.

I don’t agree with everything here. I think this slightly overstates the role of the team in deciding who should take ownership of the roles defined. It also implies that it is one person and this may not be the case. Having said that, this is one of the best distillations I’ve seen that describes a relevant set of objective for an “Agile Team Leader”.

Importantly, Patrick Wilson-Welsh acknowledges that the Agile Team Lead may delegate to a technical lead or some other specialist. I’d go further and suggest that the team will work better if this is the norm rather than the exception, especially where the team has strong experience.

This is an important line of thinking as Agile becomes more mainstream and is adopted by more organisations. It may, however, be uncomfortable for many traditional project managers and not everyone will want to adapt in this way.

I think that Patrick is beginning to articulate what we have probably “assumed” about leading an Agile team for a long time. The combination of the traits or responsibilities he has defined are as good an articulation of what I think the role should be (and I agree with him that it is essentially 1 role). One of the issues I think we’ve faced with Agile is that we know this role needs to be filled (even if it is by the “many” as some suggest) but haven’t had a place to hang it. Traditional (waterfall) PM’s often have trouble finding their place in an Agile team. Dev’s / Testers / BA’s often have trouble transitioning to the kind of leadership being described here. I’ve known highly qualified scrum masters who tend to focus internally and this can be blinkered and end up hindering a team.

I think this kind of thinking brings us closer to understanding the kind of “leadership” that an Agile team needs, and does nothing to detract from the internal leadership shown by experienced and/or committed folk within the team (leading by example or leading from within **UPDATE** I’ve just found the term “Servant Leadership” that describes this idea very well). I think there are differences between what Patrick describes and typical scrum masters although I haven’t quite found the way to articulate that – I suspect it lies in the areas of Leadership, Risk Reduction and (sometimes) continuous improvement sections identified. This view matches what I would aspire to be (as a current “Manager” of Agile teams).

Reporting on Agile Projects

Another post aimed at those new to Agile…

Although the Agile methodology does not prescribe any particular forms of reporting there are two tools or techniques that are almost always used. This is because between them they give a direct and comprehensive overview of the status and health of a project for the least effort. The daily stand up meeting, and the burn up chart tell you most of what you need to know about a project at a glance.

The daily standup meeting should give everyone in the team an up to date view of what people are working on and what problems they are facing on a daily basis. It is an extremely valuable tool for the team and helps in unblocking problems almost as they occur. If possible, the daily standup should be held near the Big Visible Plan so that you can literally point to the work on the board. Having a whiteboard handy is also a good idea so that issues that arise during standup can be captured immediately. This kind of reporting – internally to the team and to anyone else who can get to the standup – is essential to the smooth running of an Agile project.

The burnup chart is a simple graphical representation of completed scope over time (velocity). Functionality is estimated in terms of relative “points” and these points form the basic currency of the project. As each “point” of functionality is completed and approved by the customer it can be counted. At the end of each iteration the tally of completed points can be charted. It is also often useful to track points at various stages on the same burnup chart. For example, we commonly track:

• Points complete
• Points QA Complete
• Points Dev Complete
• Points Analysis Complete

This chart gives a clear indication of whether or not the velocity of the team is sufficient to complete the work planned or even if more work can be undertaken – how far have we come? How far have we got to go? Will we make it?

Standups and burnups give the team members a lot of information but they are not foolproof. Too often, stakeholders either can’t/don’t come to the regular meetings or are not located close enough to the team to see the burnup chart. They may also be used to reporting in a more traditional way. In some organisations project reporting is also centralised through a PMO and the format for reporting is prescribed.

Where I’m currently working, we prepare a written weekly status report which is shared with the team and is sent directly to senior stakeholders and management. This report contains a basic dashboard, a written summary of functionality delivered during the week, as well as a summary of the financial position of the project. It can also be very important to escalate risks and issues (some risks and issues can be effectively dealt with within the team but others need the support of stakeholders and other managers). The status report is a useful vehicle for this.

We typically have low levels of defects but reporting defect levels is also a very important factor as it gives all stakeholders a view of how healthy the output is.

If you are starting an Agile project, look to the Daily Standup and the Burn Up chart as the foundations of your reporting. Encourage interested parties to come to standup regularly. I personally don’t believe in segregating the group into “Chickens” and “Pigs” – as long as what people have to say is relevant to most of the group and they play by the rule then let them participate.

Use other tools creatively to aid communication. Written status reports have their place, I’ve also started “blogging” a status report in the form of a short narrative. In this format I’m trying to be engaging, a bit more human and hopefully slightly entertaining, including snippets of the more human side of what is going on for the team. This won’t work for everyone but at least people are interested to read it. Use what works and don’t be afraid to experiment.

Big Visible Plan

(Suitability Note, this post is really aimed at folk who haven’t done Agile before – if you’ve already used a story wall then share your experiences)

No, a “Big Visible Plan” doesn’t mean a Gantt chart printed on A3 paper. Although such a thing might impart some information about a project, it doesn’t really help you work in a “Lean” way. Lean manufacturing relies on a “pull” of inventory through the system – only enough parts are stocked to fill the immediate demand for the output. Agile, uses this principle. For each iteration, enough work is planned for the iteration but generally not more (or less!). When it comes time to decide how much work to prepare, and when to prepare it a BIG VISIBLE PLAN, or a Kanban board is a very useful tool.

Kanban is a Japanese word that means “Billboard” and in Agile we know it as the story wall. The story wall shows us all of the work that we have planned to do in the current iteration. The work has been broken down into individual stories and prioritised. Each story can have only one of a number of states. We are currently using the following list for our story wall:

 

• Backlog
• In Analysis
• Ready for Development
• In Development
• Ready for Test
• In Test
• Ready for Showcase
• Complete

Stories can move forwards or backwards through this series of states but they can only ever be in one state. There are several good reasons why a story wall is useful for a team…

Visibility is the biggest reason. At any point in time anyone can look at the story wall and see what teams or individuals are working on. This helps communication and also keeps people motivated. Each time a story jumps a column you get to physically move a card and get that little bit of satisfaction. There’s a flip side to this – anyone who is “coasting” in the team will very soon become obvious. Overall this is a good thing but if your team currently has members who are used to cruising along at their own (slow) pace, this will show them up. Expect resistance if you are introducing a story wall under these circumstances.

Communication is improved – well, if you’ve already got up out of your seat to move the card then you may as well go and tell the testers that there’s something else in their “in box”.

The story wall self manages. With a functioning story wall the days of someone walking around (project manager or scrum master for example) asking individuals what the status of a piece of work is are over. This is covered more than adequately by the combination of the story wall and the daily stand up meeting. I don’t know a good developer who doesn’t prefer this to having someone ask them repeatedly what percent complete something is.

Futurespective – The Cup is Half Full!

We’ve been running (semi) regular futurespectives as a way of taking hard earned experience and turning it into positive action for the future.

I think that one of the hall-marks of a “Good” place to work is a sense that you are making a difference, and that people are genuinely working to make things better. This kind of attitude is very hard to maintain, especially in a corporate environment, and especially in the financial services industry. As much as I respect the need for governance, stability and predictability these corporate goals often seem to run counter to innovation, creativity and empowerment in the workplace. I believe that Agile techniques are most readily adopted by people who value these things more highly than conformity and standardisation of process. But what has this got to do with futurespectives (I’ve seen it spelled “future-spective” as well)?

Most people who have participated in an Agile project are familiar with retrospectives. These are usually run at the end of each iteration and, although they take various formats, are generally focused on a theme like “What went well, what didn’t go so well, and what puzzles or blocked us”. This constant looking back is a crucial tool for driving constant improvement.

The first futurespective I participated in was run just like a retrospective but as if the group was 6 months into the future. We imagined what went well etc. Honestly, I found this to be a little esoteric and I noticed that the folk in the group who were new to Agile actually had a hard time staying “in character”. Since then I’ve used a less subtle approach that focuses on fixing problems (or pain points) and entrenching more of the “good” practices. The main material difference between this and a retro is that we’ve used it to focus on long-tail problems – the kinds of things that need more steady work or buy in from other parts of the organisation. Examples are reducing build cycle times, and increasing the amount of automation testing in the organisation. Now, I’ll take it one step further and propose the following questions as the foundation of a futurespective:

• What will we do more of in the future?
• What will we do less of in the future?
• What are the things we’re not sure about and will monitor going forward?

Okay, now it’s my turn to be a little esoteric. I’d suggest that on the face of it, the only real difference between this and a current retrospective is the tense in the questions – driving towards the future. Thinking about it a little more however, I’d suggest that this is an important shift. We do a lot of looking back, measuring, and using “yesterday’s weather” in software development but I think that there is value in institutionalizing a more forward thinking viewpoint. This has a psychological effect that shouldn’t be underestimated and I think we’re seeing benefits. Skeptics and evangelists alike become involved in solutions instead of being part of the problem. This is a significant step towards making your project or department one of those places people like to work.

In your futurespective, ask those same questions, and still decide as a group which topics are the most important, but focus more on what you will do about it or change than what went wrong. This means you run less risk of playing blame games and spend more time getting on with things. I call this optimistic analysis and it is proving effective.

Agile Management Tools – Pt II

The following are notes on several software tools useful for managing Agile projects. We have not used them all but they all have evaluation licenses available for trial. This allows a fairly complete analysis but time constraints do not – hence the rather “Pop” overviews / comments provided here (I apologise in advance if I’ve missed anything and I’m more than happy to be shown why I’m wrong

Mingle

http://studios.thoughtworks.com/mingle-agile-project-management

On the project I am currently working on we have used a tool designed and built by Thoughtworks called “Mingle”. Mingle is both powerful and complex. It can be hosted or installed locally. We have used it through two releases now and it does have a very comprehensive capability but the learning curve has been quite steep. Technical documentation is good, but documentation on how to use the individual templates is almost non-existent and so we’ve adapted.

Highlights:

• Very comprehensive
• Full reporting available
• Highly customizable / configurable
• Inbuilt wiki for storing information about stories

Lowlights:

• Configurability come at a cost – its complex
• Changing a template takes quite a bit of time and effort.
• Standard workflows are not intuitive and hard to modify
• It is easy to get things in a mess (some events trigger updates automatically, others do not and you have to remember to change another field)

Zen

http://agilezen.com/

Agile Zen is a hosted solution – it is licensed on a per user, per month basis although you can try it for free.

I don’t pretend to have used it extensively but here are some thoughts…

Highlights:

• Elegant user interface. Very useable and good-looking to boot. It is based around a story wall and the interface is a very intuitive one to use if you are used to a story wall.
• Inexpensive

Lowlights:

• I couldn’t find an effective way to represent iterations or releases (limited in terms of utility in terms of scrum or XP teams)
• Stories are represented at a high level only. The comments field is small and would not be an effective way to store information about details of a story.

Agile Bench

http://agilebench.com/

This is a fairly comprehensive tool set very squarely aimed at scrum style projects. Where I would have characterised Zen as being lighter in terms of features but heavier on design and useability I would say Agile bench goes the other way. It is more weighted to a feature set but I found it less intuitive to use – I felt a little like I should review a domain model first so that I could understand the flow of things. This is far from a strong criticism, just an acknowledgement that this tool has room to grow.

According to the tool creators this is in line with their strategy to build a strong foundation of information and add persona based flows to the system in a prioritised way. They have started by developing for tasks associated with delivery management, development, and product management. The roles of Project Manager and Analyst are slated for future development. Most of my day to day interaction (as a PM) would be with these last two hence my PM-centric view that this tool has room to grow – this is actually a positive and I’m looking forward to seeing an update.

Highlights:

• More complete “structurally” (with support for iterations / sprints, but not yet for releases)
• Clearly aimed at software development and “built for purpose”
• Would suit a wider range of Agile projects

Lowlights:

• User interface and navigation are a little to close to the underlying data structures (but remember, I’m just a simple PM). This one is not quite ready for the masses.
• I couldn’t find a useful way to store more than basic information on a story [Update: I've received further information on this and I'll check it out - looks like there IS a way - http://agilebench.com/blog/2009/09/16/how-we-got-here/]

And So…

There are many more tools available – I’ve just received information for VersionOne’s management tool although I haven’t looked at it yet. I’ll update when I do. When I received the information from VersionOne I was reminded of a quote that I think was attributable to the CEO at the time. With reference to Mingle coming on to the market he stated that “Mingle and VersionOne are not each other’s biggest competitor – our biggest competitor is Excel”. Apologies if I’ve misquoted but the idea still stands. These tools are up against a huge installed base and need to do more than keep a list. VersionOne, from a quick review of the feature set, is well ahead of the game on that score.

At the moment I’m working with a small team, in a largely waterfall development environment. For us to succeed at implementing Agile we need tools and techniques that support being Agile, and don’t distract us from being Agile. Five sixths of our team have not done Agile before this project.

Here is a run down of our main criteria…

• Our reporting requirements are not complex – basic burn charts convey most of what we need to know.
• It is important to this team that the capture of information about stories is thorough (room to grow, and save information about the conversations that occur, as well as acceptance criteria)
• The tool should support us being Agile, not distract us (see above)

For now, we have a small enough team that the free 5 user licence for Mingle will continue to work for us (using roles rather than individual logins). Mingle has proven to be a mixed bag with some features supporting what we do and some “forcing” us to rethink our process (or spend probably too long working out how to change Mingle). We could happily continue but the team is also interested in trying another tool. Maybe this is a little reflective of the “Shiny Toy” syndrome but at it’s heart is an enthusiasm for the method and an eagerness to embrace. Mingle has hampered us in the past but now we’ve gotten through a learning curve with it and we feel like it is more “supportive”. Workflows in Mingle need to improve for us before I get a warm feeling about it.

I love the interface of AgileZen but don’t think it has enough flexibility for the current circumstances. I’m counting this one out for now.

Agile Bench has many things going for it and I sense that the next version might be very close to the mark. It contains the right kind of information for us, I think we just need a slightly easier way to get to it.

True to form, I’m taking this information back to the team and we’ll decide together…

Agile Management Tools – Pt I

Tracking the progress and status of Agile projects has some interesting challenges. On a waterfall project status is typically “gathered” by a project manager through a series of reports and consolidated. Gantt charts are common, and percent completes are everywhere. There’s nothing inherently wrong with this but on an Agile project we’re aiming to condense the complete development cycle for a series of features into a short period of time (two weeks in our case). This means that status really does need to be up to the minute (or at least up to the day). You need a way to indicate status and progress that not only self manages, but allows everyone to participate.

One of the good things about a story wall is that it gives a complete and current picture of what has been completed, what is being worked on now, who is working on it, and what is coming up next. Big and visible. Most of the teams I have worked with have used a combination of Excel and a wiki to underpin the story wall – Agile suggests that we shouldn’t over-document but it doesn’t suggest that we don’t document at all.

A master story list (MSL) is very important. We need to be able to capture the list of things we did, how many points we estimated for them, when new stories were added and so on. If we can’t measure these basic things then we have no real basis for realigning our velocity and also working out how much things cost and how much future features might cost. This kind of thing is not immediately necessary for the functioning of the team but it is important for planning. Excel is a perfectly adequate tool for managing an MSL – it can filter, sort and sum. It is not a good tool if you need to have more than one person updating it.

A wiki is a good place to capture requirements on an Agile project. It is collaborative, ideas can be shared, documents attached and so on. It is not prescriptive in terms of content so the content fits the conversation, meaning that only the important details need be added. The wiki, although useful has a potential shortcoming where testing is concerned and this is where I have found the most problems with this simple approach. Acceptance criteria can be effectively documented in a wiki, test cases and scripts are best suited to some other tool. Why? Mostly because of governance. What were the tests that were run? Did they pass or fail? Did they get run a second time? Metrics around testing are often the most scrutinised where releases are concerned and surety is important. Also, testing governance is often mandated by a separate group in the organisation and so often, testing governance = “Quality Center”. This means another tool gets thrown into the mix.

Another observation – test automation is probably the single biggest thing you can do to really mature your Agile process. It is also hard to do well, and often the last thing to get thought about (too late?).

In general, I’m a supporter of making things simpler so the idea of having a single tool that does all of the above is very appealing. This post is really about kick-starting a journey to find that tool. But first, why look for a tool? Why not just live with the simple (and basically free) tools we have? Okay, Excel is technically not free but it lives on most corporate desktops already.

Reason 1 – Collaboration. Personally I’m very happy with a story wall and the visual immediacy that brings. I’m also happy, as far as functionality goes, to live in the “high level” world of story descriptions but I completely acknowledge that for the team to do it’s job effectively some more detail is required. What happens though when that team is spread out (co-location is not everybody’s reality unfortunately and we are seeing more attempts at off-shoring).

Reason 2 – It feels good. Face it, a lot of people like having this sort of thing stored electronically and accessible / updatable by the whole team. No matter what their role. No matter where they sit. This is more compelling than you think.

Reason 3 – Automation. Automation is good right. If you need to report a status regularly or if you want a senior stakeholder to be able to see at a glance how things are traveling on your project then you’ve got two choices – either add up the numbers yourself every day, or have a constantly updated repository that does it for you. The story wall is a snapshot and it’s a great way for a collaborative team to work. It’s even a great way for a stakeholder or interested party to see what is going on if they either site near / with the team but it is not all things to all people.

Next up: What tools are out there and why choose one over another…?

Late Adopters Club – The blog of Ashley Ternes

I’ve always been a late adopter. I’ve just never liked fads and somehow that has cost me a few “cool points” over the years. I couldn’t walk the dog when Yo-Yos were big (yes, Yo-Yos, for anyone under the age of 35 check this out http://en.wikipedia.org/wiki/Yo-yo).

So let it be with blogging. The time has come however for, at the least, a professional presence on the dub-dub-dub. This is it…

So here’s a short summary:

• Ashley Ternes
• Ex-software developer
• Present day IT project manager and Agile coach – currently doing both in the financial services industry
• I’ve been practising Agile for around 6 years and I’ve worked with some exceptional people. I don’t count myself as exceptional, but I have learned a few things.

This blog is focused on Agile for those wanting to try it, or trying to build it. My most recent experience is in introducing Agile to an essentially non-Agile development group, so that’s what I’m going to write about.