Here's another great list from Marios Alexandrou: Project Management Lessons from NASA

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

The Register's reader poll about distributed software development does not paint a particularly inspiring picture...

When asked how distributed software development was managed within organisations, almost half said things were not that great. About a third gave feedback indicating that they were just about doing okay, but only one in five said things were managed well.

See here for The Register's poll results...

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by blogrodent

read more

Marios Alexandrou has posted 21 great project management truisms on his blog...

Enjoy!

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

In traditional waterfall projects, it's quite common to have a two-stage approval process, especially when it comes to raising funds to develop a new idea.

Stage 1 approval provides sufficient funding to get a project started and complete the analysis phase. Once analysis has been completed and a detailed specification written, the project can be more accurately estimated and a further request is made for full funding of the project.

So how would you tackle an agile project with this kind of approach to the funding?

First of all, this two-stage approval process for funding a new project is still valid with an agile approach. It's simply an unavoidable reality that some work has to be done before a project can be reasonably well understood and estimated. And this work, unless there's a permanent team already in place, needs funding before an investment decision can be made.

So, in an agile project, what outputs might you produce with the initial funding? You certainly wouldn't want to complete a full analysis phase and detailed specification. But you would need something.

Here are some ideas:

• Visuals or Wireframes
  
• Research (User/Customer/Market Research)
• Prototype
  
• Proof of Concept
  
• Technical Feasibility Study
  
• Initial Product Backlog (feature list)
  
• High-level Architecture
• Technology Selection
  
• Estimates
  
• Team/Resource Requirements
• Release Plan/Product Roadmap
• Costs
  
• Business Case
• Project Initiation Presentation

Whether or not you produce all of this depends entirely on your project, of course, and whether or not you feel it is of value. In any case it should be high level, not fully comprehensive. Sufficient to shape the project and understand the requirements and solution better. Sufficient to understand how much funding should be requested to complete the project.

If initial funding permits, you may also be able to establish the project team and complete a few short sprints, in order to understand the team's Velocity for planning purposes. But this would depend not only on the initial funds available, but also on the likelihood of full approval.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by tico bassie

read more

Rob Thomsett, author and consultant, got the graveyard shift at the Agile Business Conference in London today. Rob says, above all, implementing agile is first and foremost a culture change. For sure, it changes the role of project managers in software development. But it doesn't eradicate the need for project managers. Project management is absolutely still needed.

I've blogged quite a bit recently about how I believe the same. More work can be done as Business As Usual when using agile methods. But for larger projects, agile software development needs to be augmented with good project management practices. In these cases, agile software development alone is not enough.

Rob is a very entertaining speaker - no sleeping here! Some really interesting home truths. About executives' view of projects, and how the IT industry has so consistently failed to deliver on projects for the last 40 years.

One of the biggest challenge with any project, agile or not, is managing scope. Rob has never believed that requirements can be fully defined up-front. Getting Project Sponsors to pay any attention to their projects is also a big challenge. Sponsors need to clear a space in their diaries, and play an active role in their projects!

Rob says he hates the term 'Users'. He remembers in the IT dark ages, when everyone thought Users were stupid. On the evolutionary scale, somewhere between pigeon and monkey! Agile development changes this. It builds trust. Trust between the Experts and 'Users'. It starts to create a partnership. A real partnership between IT and business people.

Projects must have an open relationship with stakeholders. The only purpose of delivering projects is to deliver what the stakeholders want. Stakeholders are not the enemy. Projects must engage stakeholders as allies.

On his website, Rob has some estimating games. Things like "guess the number your boss is thinking of", "double it because the boss will halve it", stuff like that. They sound fun!

Agile Project Management principles should be openness, honesty, integrity. Also simplicity, face-to-face communication and no bureaucracy!

Rob says the software development model (analyse, design, develop, test and implement) is still right. It's the artefacts that are wrong. Don't throw out the model. Agile still needs these processes. But do throw out the artefacts. Remove the bureaucracy!

He also talked about an idea he has for a reality TV programme - Bureaucrats Survivor! where bureaucrats are stranded on a desert island and have to survive. He said they'd probably start by cutting down all the trees, so they can make forms! Only then would they realise they needed them for fruit :-)

Rob showed an interesting tool for defining the success criteria for projects. He called it "Success Sliders". It's a tool to help facilitate a conversation with stakeholders about what's important for them on the project. A way to align stakeholder expectations. Looks really interesting if well facilitated - well worth a look!

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

Now I'm in a session called 'Agile Development: Enterprise Delivery', being presented by bjss. They're using agile development techniques on an enterprise scale project, where the customer wants fixed budget, fixed delivery date, and the scope is also fixed because the project's replacing an existing system...

Now we all know that's a challenge in software development, whatever methodology!

The project is to deliver a high volume (5-10,000 orders per second), high performance trading system, with thousands of users and a big bang delivery. It's a significant revenue generator, and the project is a 1-2 year programme. Sounds quite scary, but so far doesn't sound very agile!

Added to the scale of the project and complexity of the solution, the customer is also more used to a traditional, waterfall approach to software development projects. The customer thinks they need something more agile to help mitigate some of the risks, but they also want their cake and eat it: they want to know exactly what they're going to get and when, because the deadline needs to be publicly advertised.

One way they're mitigating some of the risks is to deal with the most difficult, risky things first. As usual in agile, they're also of course breaking the project into small iterations, testing early, and taking a very collaborative approach to the project. Likewise, user acceptance testing is a continuous process throughout the delivery.

They're very risk focused, asking every day "what can we do to reduce the risks?". It's a very architecture-centric approach. They did a PoC (Proof of Concept) first, in order to test performance, new technologies and some key aspects of the architecture.

They didn't go into every detail on the architecture up-front, but they did have a high level view of the overall architecture, in order to understand the solution context and the key interfaces.

The project is use-case driven. Iterations are delivered to the users, even if they have little functionality. User representatives can actually use what has been built throughout the development, even if there's not much to the solution yet.

The project is structured into small, autonomous "cells" (multi-disciplined, agile teams). An architecture team was formed first, with other teams coming on board asap. The high level architecture allowed the solution to be divided into distinct parts, allocated to the vertical teams.

The project is very *team* focused. They are committed to the approach. They have clear roles and responsibilities. They are honest with each other and they happily help each other. They are empowered to make decisions. They prefer face to face communication, and they work hard to keep the team motivated.

The team leaders for each team meet every day in a Scrum of Scrums to keep the leadership group joined up and aware of progress and issues.

They only document what is necessary and only sufficient to meet the purpose. Documentation has a short lifetime. Instead they tend to focus more on workshops, collaboration, whiteboarding sessions and short design notes.

They have one rule - Never break the build! They automate as much as possible. They run *all* the automated unit tests on *every* build. The team fixes any problems as and when they arise.

In terms of quality, their mantra is 'keep things simple'. They test early and often. They turn on all warnings and fix everything they find. They measure test coverage. And customers test continuously as releases drop.

The choose their tools carefully, depending on the needs and nature of the project, making sure they have the tools to help measure test coverage, handle refactoring, automate tests and builds, etc, etc.

Although the development teams are working in a very agile way, from a project management perspective, they do keep a strong focus on the bigger picture and the end game. Use-cases move between iterations quite regularly, but they measure progress using some key metrics. For example they track % complete (using earned value), velocity, efficiency, defect count/detection rate, and test progress. These metrics are used for communication with the customer, and also for forward planning.

Regular demonstrations and iterative delivery are key to the software delivery. But they also do have some traditional project governance, sitting over the overall programme, e.g. status reports, RAG status, a gantt chart showing the iterations and any non-development aspects of the project. They also do resource profiles, track risks and issues and manage project budget.

So, in their experience, you can have your cake and eat it too!

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

A little while ago I wrote about agile project management and how agile project management alone is not enough.

One area agile methods don't really address is project status reporting.

Obviously the daily stand-up (or daily scrum) is a good form of status reporting. It's great for people with a close interest in the project who can spare the time to get to the scrum.

But it's really no good for other stakeholders that can't get to the scrum each day, either because they are interested in less detail, or because they have an interest in many projects and can't be at all the scrums.

For people like this, a traditional project status report is still important. But traditional project status reports often have their problems too. In my experience, they are often too wordy, sometimes leaving you to find the essence of the report in a sea of useless information.

In my view, the answer is simple:

The burndown chart.

For a regular project status report, calculate the burndown chart using the entire product backlog for the project, not just for the current Sprint. Forecast what future Velocity you think can be achieved based on the team's past performance. The forecast line will allow you to forecast the project's likely end date.

The burndown chart gives a really clear indication of status. Particularly if the team is very disciplined about the definition of done. Importantly, the status is obvious at a glance. So it's really good for stakeholders that can't get to the scrum, providing the key information without losing the point in lots of words.

If the project is running behind, or facing key issues or risks, they obviously warrant a brief explanation too.

The other key dimension on most projects is cost. Why not create another burndown chart for the project's costs? If the forecast line reaches zero before the planned line, you're running over budget and (unless you finish early) you will run out of funds!

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

Jeff Sutherland is well known as one of the co-creators of Scrum, one of the leading agile development methodologies.

In this video, Jeff talks about his visit to Google - where he analysed one of their first implementations of Scrum on one of their largest distributed projects - and shares the lessons they learned...

Agile Project Management: Lessons Learned At Google


P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

Projects are a necessary evil :-) But necessary they are.

Some people really feel the need to understand precisely what the project will cost and exactly long it will take. If this is the basis for investment, of course that's a completely understandable feeling.

For years, traditional waterfall projects have been sold on the false pretense that projects are predictable. Plannable. Of course the reality is, projects are highly unpredictable, and - sadly - that's why so many projects fail to meet expectations.

So when you need to plan a project, in order to forecast the overall costs and timescales, how do you do this for an agile project?

Well, of course, agile development is no silver bullet.

If you are bad at planning, bad at identifying and sticking to at least the broad scope of the project, bad at estimating until you have all the details, bad at controlliong delivery, an agile project plan is likely to be just as bad as a non-agile one!

The benefits of agile development are more to do with early realisation of business value, early visibility when things are going off track, collaboration and regular feedback to ensure quality and provide the right solution, and so on.

Yes, there are also some important benefits in the approach to estimating, but fundamentally, planning a complete project up-front and committing to costs and timescales is still, of course, a potentially potted process. A process full of pitfalls. And a process that requires great skill and experience to get anywhere close to predicting something that will resemble reality.

But, with that caveat in mind, here's how agile project planning works...

Agile project planning is generally referred to as 'release planning'. The concept of an agile release plan is about planning multiple Sprints that culminate in a release of the product. It is not necessarily project-oriented, however the concept for projects is of course the same.

PRODUCT BACKLOG

First of all, you really need to get your Product Backlog in order!

The Product Backlog is essentially a feature list. Above all, it's user-oriented and lists features in a language that business people and users understand. It's not technical. And it's not a list of tasks. Do not attempt to list all the tasks for the project and identify all the dependencies. Just list all the features the project needs to deliver.

Also include any lasting deliverables that are not necessarily part of the software. For example a User Manual, or a Technical Reference Document for any API's. However do not list the *temporary* deliverables that are just part of delivering a feature. For example don't list the analysis tasks or design documents for each feature. Try to keep it as a list of product features and only include deliverables that outlive the project.

What I'm about to say is an important point about any planning process, whether it's agile or not, so listen up! :-)

There are generally only two things that cause your plan to fail: 1) You under-estimate the things you've identified; and 2) you don't manage to identify everything . If you only estimate the items you identify, the quality of your Product Backlog is a critical success factor for your project.

BUSINESS ANALYSIS

So surely I have to do a complete analysis up-front to make sure I've identified everything, right? Yes and no. If you're going to plan a complete project, even if it's an agile project, you do need to do *enough* analysis to identify all the features you think you need to deliver.

However, unlike in a traditional analysis with a specification, you really do not need to identify all the details about how each feature will work. Just enough analysis to list all the features, with a degree of confidence that the broad scope of the system is covered. The details can be left until later, and be dealt with just in time for the feature to be developed.

So it's very important that the Product Backlog is at an appropriate level of detail. This, in itself, is a mysterious art. If the items are too detailed, and you estimate only what you've identified, there is a high chance you'll miss some things out. But if the items are not detailed enough, there's a high chance your estimates will be wrong.

Because agile estimating (which I'm coming on to) is based on broad, relative size of each feature, you do not have to break down the features too small at this early stage when trying to estimate the overall project.

For example, it's probably sufficient to know that users will need to be able to register and log in. It's probably not necessary to itemise what details they will need to enter to register, and how the system will authenticate the login. Unlike traditional projects, you certainly don't need to worry about how long will the fields be and what validation will be needed, and minor details like that. The details can be sorted out later.

When you are reasonably confident you have a comprehensive Product Backlog that broadly covers the scope of the project, listing all the features that need to be delivered by the project - not too detailed but detailed enough to compare the relative size of each feature - you are ready to do your estimates.

ESTIMATING

First of all, do your estimates as a team. 'Planning poker' is a method where each team member writes their estimate on a card and all team members reveal their estimate at the same time. This is quite fun to do and is a great way to get everyone's estimate before they are influenced by others. Wild discrepencies in people's estimates are a great discussion point, a way to identify differences in understanding early on, and a way to understand different people's perspectives about the implementation.

Secondly, estimate your features in points. Many agile teams use the Fibonacci numbering system to do this. The points represent the relative size of each feature. For example, a feature with a 2 is roughly twice the size of a 1, which is very simple. A feature with a 5 is a bit more than twice the size of a 2, and a 21 is much more difficult.

Basically it's the relatively of this estimating approach that is important, not the number itself. The philosophy is that people can't really tell you accurately how many days or hours it will take to implement something they know little about, but they can tell you whether they expect it, on average, to be easier or harder than something else.

When the whole Product Backlog has been estimated, you now know the 'size' of your project, but it's in abstract points rather than in real units of time. How do you convert this into a cost and timescale?

PLANNING

If you are going to utilise an existing team that are already doing agile, and you know their average Velocity per Sprint, it's easy. Just calculate how many Sprints it would take to burn-down the number of points on your project's product backlog.

If, however, you're establishing a new team, that has not done agile before, you have no idea what their Velocity might be and this is another potted part of the planning process. Basically you need to make an assumption about the team size and its Velocity. In this case, this how I would do it...

Get more than 1 developer, of varying skill and experience, to look at a small section of the Product Backlog. Ask them how much they think they could complete in a single Sprint. Remember to explain what you mean by complete, i.e. done means DONE!, so you know everyone is working to the same basic assumptions.

Compare the number of points each developer has effectively said they can complete in a Sprint and decide what you consider to be a reasonable average based on what you've heard. Using that average number of points, assume that's your Velocity (per person) and calculate the number of Sprints you would need to complete the entire Product Backlog. This calculation will give you your approximate project duration based on 1 developer.

SUMMARY

Now you can make an assumption about the size of your team, based on the available people, the target timescales or the amount of funding you could potentially raise, and cost it up accordingly.

As with all projects, it would be wise to add a contingency. As I mentioned earlier, it's often the features you didn't list that cause a plan to fail. The contingency should reflect your level of confidence in the quality of the Product Backlog. If you think it is thorough, and the project is unlikely to be prone to lots of change, maybe you should add about 10-20% to your project. Otherwise it might be wise to add more.

Remember, though - although agile estimating and planning does have some distinct advantages, it is not a silver bullet. The care and attention you put into this process, along with the skill and experience of your team, in the end will really determine how likely your plan is to succeed.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

On BAU (Business As Usual) development, an agile approach makes a lot of sense.

Moving through iterations, working on features from the Product Backlog, collaborating with stakeholders about the requirements for each feature, delivering working software incrementally.

But what about Projects? (that's Projects with a capital P). In an agile environment, do we still need Projects?

Or is everything literally broken down into small incremental pieces. And Projects, as we knew them, cease to exist?

Imagine life without Projects... Bliss! Or would teams just slip into a treadmill of ongoing Sprints and lack any real purpose.

Debate.

One thing Projects definitely do provide, usually in abundance, is focus. And a real sense of pressure to deliver. With that pressure, often comes intellectual challenge, motivation, team spirit, and a bunch of other positive things too.

Unfortunately, with that pressure Projects also often come with a lot of hassle, over-spending, late delivery, features that don't meet expectations, and a lot of disappointment.

But the reality is, Projects are still necessary in an agile environment.

If for no other reason, they are necessary because the people funding the Project (whether that's external customers or internal sponsors) expect to know what the outcome will be, if they invest their hard-earned money in your Project.

What, exactly, will I get? Exactly how long will it take? What exactly will it cost? How can you assure me the project will be a success?

Obviously in traditional software development projects, people have known these details precisely, because they've specified everything up-front and planned everything in detail :-) And of course things are always then delivered to those expectations, right? :-)

Of course not.

Of course we all know it's a false sense of security, and in reality there is little that will really assure the people funding the Project that they will actually get everything they wished for, on time and in budget. According to independent research, 75% of projects fail to meet expectations. Fact.

But still, Board members and customers continue to expect the impossible. Expecting development teams to predict, up-front, the outcome of their Project in terms of cost, time and quality/scope/features. Fixing all three dimensions.

Unfortunately, however, this is the culture in which most companies operate. It's what they are used to.

Until the 2nd or 3rd generation of agile teams is coming through, and the 1st generation of agilists are in senior positions of influence with customers or the Board, this false expectation will continue to exist.

So Projects are necessary. A necessary evil, maybe? But necessary.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by dotbenjamin

read more

Ideally, agile principles should be applied long before a project reaches development.

I've written recently about how PowerPoint can be used as an effective lightweight alternative to a traditional PID (Project Initiation Document).

I've also posted a sample template for an Agile Project Initiation Presentation (PIP).

In these slides, the first handful of slides can be done right up-front, just to provide some basic information about the vision, in order to get some initial funding ('seed money') to proceed into an 'elaboration phase'. The purpose of the elaboration phase is then to get into more detail, in order to understand the project and its costs better, before requesting the full funding required for the project.

In traditional projects, this elaboration phase would include detailed analysis, a full specifcation, maybe a complete technical design, and a detailed project plan.

In agile projects, the elaboration phase would instead focus on identifying the user stories for the product backlog (not detailing them), prioritising the backlog, high-level process (as-is and to-be), high-level estimates, high-level architecture, outline release plan, project structure, and any key risks, etc.

In many ways it's similar to a traditional project approach, but it should be much more collaborative, inclusive, timeboxed, highly visual and lightweight; not in word form and not detailed. And not months to complete.

One of the common problems with project elaboration phases, in traditional project management methods and with agile methods, is that they often need to happen before a project team is properly formed, and therefore before all the key roles are in place. This causes delays and can cause major problems for the project further down the line.

These slides from ThoughtWorks describe some of the typical problems really well, and offer a potential solution. The idea is simple. The idea is to apply agile principles early - right from the very inception of a project. Even before the project is broadly defined, agile workshops can facilitate a gathering of all the key roles required to elaboarate a project quickly and effectively.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

I recently wrote about Agile Project Initiation, and the idea of using PowerPoint as a lightweight alternative to more formal methods of kicking off projects.

Here we've implemented a presentation template, and called it the Project Initiation Presentation (PIP). On larger, agile projects, it takes the place of the PID that may have been used on more traditional projects.

This kind of presentation is typically used to present to senior management to secure funding; to present to the project team to share the vision of the project; and to present to wider stakeholders interested in the project and its outcomes.

So what would be in such a presentation?

I've posted a sample Agile Project Initiation template on the allaboutagile Google group. The information on the slides is completely made up; just a dummy project to give you an idea of what it might be like. For each slide, the slide notes provide some guidance on what should be on the slide. Of course, anything that is surplus to requirements for your project can simply be deleted as appropriate.

Hopefully you'll find it useful! Your feedback, as always, is very welcome - let me know what you think?

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by David Prior

read more

I've written before about how I think Agile Project Management alone is not enough. Project Initiation is one of the areas of agile methods that I think needs embelishment for large projects.

Over the years, I've used quite a few techniques for project initiation.

But I've never really come across an agile one.

My first experience of formal project initiation was a Project Definition Report in Method1, a very traditional methodology from Anderson Consulting as they were known then; now Accenture.

Then, as a Project Manager, I used a PID (Project Initiation Document) from the PRINCE2 project management methodology, which I guess is probably the most widely used today.

In MSF (Microsoft Solutions Framework), there's the Vision & Scope document.

Truth is, they're all pretty similar really. Long documents, with lots of details about a project and how it's going to be run. Long, tedious documents.

Yet, for large projects, they are important.

As a Project Manager, I always found the thought process they made me go through was incredibly useful. I personally benefited from writing them; that's for sure. Without them, the project could be poorly thought through. And the chances of failure would certainly be higher.

So the thinking was valuable. Trouble was, no-one wanted to read those lengthy documents. All that thinking. All that writing! And no-one was really interested, truth be known. Not the Project Board. Not the project team. And certainly not the wider stakeholders.

So, if the thinking is valuable, what do agile methods have to offer instead?

Nothing.

Unless I've missed it somehow. Nothing.

So, for large projects that warrant it, how do we incorporate this valuable thinking into agile methods? And how do we do it in a way that people will actually pay any attention to?

The answer is simple.

Do it in PowerPoint.

Producing this information in PowerPoint has some profound effects:

1. It's easier to write. In PowerPoint, the writer is naturally more concise, because of the constraints of the format.
   
   
2. It's easier to read. It's natural in PowerPoint to convey things in a more interesting and digestable form.
   
   
3. And it's easier to share. Invite people to a meeting or presentation, and they'll happily sit through a PowerPoint to understand the goals of a project. The speaker - aided by the slides - brings the information alive. Ask the same people to read a 50 page project initiation document and, surprise surprise, the response is different.

Thinking a project through before kicking it off is valuable.

Being able to communicate this thinking to others is imperative. To get funding; to share the vision with the team; to inform other stakeholders about the goals of the project.

So next time you need to do a more formal project initiation, why not try it in a format that's more appropriate for the purpose?

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

For agile project management, agile development methodologies, such as Scrum and eXtreme Programming, alone are not enough.

Scrum is excellent for managing a project team's workload and delivering products incrementally through iterative development.

eXtreme Programming (XP) is excellent for agile engineering practices that improve product quality, and User Stories from XP are an excellent way to simplify the understanding and management of requirements on a piecemeal basis.

If you're not familiar with it, take a look at the Project Management Body Of Knowledge (PMBOK). This body of knowledge is a globally recognised standard and was put together by the PMI (Project Management Institute). It encapsulates common practices for project management irrespective of specific methodology.

Although PMBOK really embodies all we 'agilists' refer to as traditional project management, it is a very useful resource. No doubt it includes traditional project management practices that are not appropriate if you are doing agile. But it also includes key aspects of a project that need managing which are simply not addressed by Scrum or eXtreme Programming.

For instance:

• Project Initiation
• Cost Management
• Human Resources Management (hate that term, but important nevertheless!)
• Communications Management
• Risk Management
• Procurement Management
• Stakeholder Management
• Organisational factors

Sure, in agile we don't want to see a big specification up-front. We don't want to see every task mapped out on a huge gantt chart. We don't want to see change control as the process for scope management. But we do need the above list of things managed in many agile projects.

So how is this overcome in practice? In my experience, it is overcome by having a 'traditional' Project Manager, who understands project management (such as PMBOK, or the PRINCE2 project management methodology that has become the standard in the UK), who can apply the relevant aspects of the traditional PM approach with the agile practices of Scrum and eXtreme Programming. Effectively augmenting agile with traditional project management methods where appropriate.

Wow! In my view that requires a lot of skill, knowledge, experience and expertise. To understand Scrum, eXtreme Programming and PMBOK, and somehow blend it all together to create a method that encompasses agile management, agile engineering and project management. All the time still retaining the agile mindset and satisfying stakeholders that are used to a more traditional project approach. And without a clear industry reference point to help convey the blended process to all stakeholders and members of the project team.

Is it my imagination, or are we missing something important in the agile community?

Is there anything similar to "PMBOK'' for agile? Is there something that blends PMBOK with Scrum and XP, in order to create a comprehensive methodology for managing agile projects. Something described in a way that is easily accessible to all roles in a project, not just those that are experts in the subject? If there is, I'd really like to hear about it...

Kelly.

P.S. Click one of the icons below to join the growing community of people reading this blog by RSS or by email...

read more

With an agile development approach, there is no big spec and no big design up-front. Scope is variable. Requirements emerge and evolve. Features can be added, changed and removed throughout the project lifecycle.

So, with this moving target, how do you keep sight of the bigger picture?

Although agile development is all about breaking things down - breaking things down into micro pieces and delivering on a piecemeal basis - it is also very important to have some overall guiding context.

From my perspective, this context comes in 3 major forms:

• Business Context
• Project Context
• Solution Context

Business Context

What is the business vision? What are the challenges and opportunities from a business point of view? What are the business goals - short, medium and longer term? Who are the customers? Why do they buy, and what do they use the solution for? What do they like and dislike about the product? Who is the competition and what are their solutions like?

Without this over-arching contextual information, any product development team is working with a major disadvantage.

In my experience, development people can be quite innovative. With this information - if development teams have a real insight into the business context - people on the development team can be proactive. Without necessarily being asked to work on a problem, or without being asked to come up with an idea, solutions to problems and new innovations will come to mind.

Project Context

If the development team is working on a project, many of the things defined in a more traditional project initiation phase are just as important in an agile development environment.

What is the specific problem or opportunity that the project is seeking to address? What is the vision for the project? What are the project objectives? What is the scope (broadly speaking)? What is the likely cost and timeframe? What are the benefits and how will they be realised? Who will work on the project and what is the project structure?

The answers to these questions (and more, of course) give people important guidance. And that guidance is more important than ever in an agile development approach, because of the freedom to change things along the way.

With this guidance, the project team has some parameters to work within, and a clear understanding of the expected outcomes.

Solution Context

I'm a big fan of User Stories. I've written quite a few entries on my blog about them recently, and how to write good User Stories. I love the fact they are so small. So self contained. So manageable. It really does keep things simple. But what should you do before you get down to the detail of individual User Stories?

It is important to look at individual User Stories in context of the overall solution. So what artifacts help us to do this? There may be others, but here are some things I certainly like to see before getting down to User Stories on a Sprint-by-Sprint basis:

• High-level Product Roadmap - broad timeline across the top, perhaps in months or quarters; highlighting key product features or milestones. Unlike a plan, a Product Roadmap is indicative and evolves as things change. This provides the team with some structure around Sprint Planning, with the Product Roadmap helping to inform the priorities of each Sprint and set Sprint Goals.
  
  
• High-level Visuals - this could be wireframes for key screens, Creative visuals of a web site, a conceptual story board for the UI (User Interface), etc. Whatever form it takes, it's a high level outline of how the solution will hang together from a user's perspective. The visuals don't need to cover every single screen. They don't need to show every feature. And the solution may not look exactly like the visuals when it's finished. In fact it almost certainly won't. But it's a guide to what's intended at the outset, and should cover the main scenarios for an everyday user.
  
  
• High-level Solution Architecture - this doesn't need to be a detailed design, but you do need some architectural guidance in order to understand key technologies, product structure and how the overall solution hangs together from a technical perspective. In my view, this can be an evolving picture, the kind of thing that is sketched on a whiteboard at the start of the project, with more details being filled in as the project progresses and as technical decisions are taken.

Summary

So, in summary, an agile development team might break things into small pieces and deliver incrementally, but this makes it even more important to have the overall context always in mind. My advice would be to keep key guidance artifacts (such as project objectives, product roadmap, solution architecture) high level, lightweight and visual, and stick them on the wall along with the team's User Stories and daily tasks.

Kelly.

P.S. Click one of the icons below to join the growing community of people reading this blog by RSS or by email...



Photo by b1uefish

read more

ExtremePlanner has announced the publication of a new agile project management book, written by their founder David Churchville.

The book is called "Agile Thinking: Leading Successful Software Projects and Teams".

It's essentially a compilation of over 40 blog posts from his blog, Agile Project Planning, although apparently it's been edited to make better reading in book form.

And that got me thinking. I've written over 100 entries for this blog now. Most of which have been serious attempts to share knowledge and experience about implementing agile principles and practices. Maybe one day I could make a book too? :-)

read more

The key principles of agile software development help to mitigate many of the common reasons for project failure.

In particular, the incremental approach and active user involvement guard against one of the biggest risks. The risk of building a software product that doesn’t meet expectations. The risk of building the wrong product.

But how does agile software development help you to manage risks that fall outside the development process? The risks that aren’t inherently reduced by an agile approach.

Here I take a look at how you could incorporate a more traditional approach to risk management, within a project that's using an agile approach...

In a more traditional PRINCE2-based project, you would keep a risk log. Typically a risk log would include the following information:

• description of the risk
• date raised
• likelihood - description of its likelihood and rating (1 unlikely, 2 possible, 3 likely)
• impact - description of the impact and rating (1 low, 2 medium, 3 high)
• mitigation - what could or should be done to reduce the likelihood of the risk?
• contingency - what will we do if the risk becomes an issue? What should we be doing to plan for it's eventuality, particularly if it's likely
• actions (with dates and owners)
• last updated - when the entry in the risk log was last updated and by who

You can keep a risk log in agile projects too. Of course. There are no rules in agile which say you must not use any other management approaches or artifacts in conjunction with an agile approach.

But how do you make something like a risk log more akin to agile principles? And how do we integrate this kind of risk management within the iterative cycles of agile development? Here are some suggestions...

1. Make it visible. Put it on the wall for all to see. For the team, project manager, product owner, etc to see every day in the daily stand-up meeting.
   
   
2. Make it collaborative. Allow anyone to add a new risk or add comments on an existing risk any time they want.
   
   
3. Make it visual. Put the likelihood and impact in a 3x3 grid, so likely risks with high impact are top right (in red) and unlikely risks with low impact are bottom left (in green). Each risk then gets a score of 1-9, i.e. likelihood*impact.
   
   
4. Make it part of the process. In Sprint (iteration) planning - as well as asking what went well, what didn't go so well, what would we do differently in the next iteration - also ask what could prevent us from meeting our objectives? For the Sprint and for the project as a whole. Facilitate the team's thought process to actively identify risks. Add them to the risk log on the wall.
   
   
5. Include it in the product backlog ('feature' list). If it's appropriate to do something to mitigate a risk and reduce its likelihood, or to prepare contingency for the risk, add the actions to the Product Backlog for the project and prioritise them along with the features. The Product Owner is then taking business responsibility for the risk and its priority relative to features of the product. If a risk occurs before the mitigating actions are reached, this was a knowing commercial judgement about its priority and not a failing of the team to identify or highlight the risk.
   
   
6. Review it daily. In the daily stand-up meetings - as well as asking what have you done since the last meeting, what will you do before the next meeting, and if there anything holding up your progress - also ask each team member if there's anything that could prevent them from meeting their goals. This will encourage a little proactive thought, not just reactive when progress is blocked.
   
   
7. Make it the team's responsibility (to identify and highlight risks). By asking the team to identify risks during planning meetings, and within each iteration. By asking the team to rate the likelihood and impact. By asking the team what could be done to reduce a risk's likelihood. By asking the team what we would do if the risk materialises. However the priority of a risk is still a business decision. It's up to the Product Owner to decide on the priority of a risk, in relation to other activities on the backlog.

In other words, on major projects particularly, make risk management part of your everyday business.

See also:
Why most IT projects fail. And how agile principles help
A sad indictment of the software development industry
10 Key Principles of Agile Software Development
10 Key Principles - PowerPoint presentation

read more

Some argue that an agile development approach is right for any project. Others argue that agile is a hoax :-)

Of course the reality is somewhere in between.

I'm sure you can apply agile principles, or a more traditional approach, to any project. The best way to approach anything is often the way you know.

Although I'm sure that some projects definitely suit agile more than others.

Personally I think agile suits more projects than not - due to human nature and the evolutionary nature of software development.

But how do you know whether you should use agile for your project? Or whether or not your typical projects suit agile? How do you know if agile is right for you?

DSDM (Dynamic Systems Development Method) is one of the earliest development methodologies based on agile philosophies. The DSDM methodology includes a project suitability filter.

This filter is a simple questionnaire that attempts to highlight the key characteristics of a project that is well suited to DSDM, or more generally to an agile approach. Here are questions:

• Does the sponsor/senior management understand and accept the iterative philosophy?
• 
  
• Is there senior user commitment to provide active user (or user representative) involvement?
• 
  
• Can the organisation accommodate the frequent delivery of increments?
• 
  
• Will it be possible for the developers to have access to users (user representatives) throughout the project?
• 
  
• Will the development team remain the same throughout the project?
• 
  
• Will the development team have the appropriate skills?
• 
  
• Is there a supportive commercial relationship?
• 
  
• Will the project use technologies suitable for prototyping?
• 
  
• Is there a highly demonstrable user interface?
• 
  
• Is there clear ownership?
• 
  
• Will the development be computationally non-complex? (agile can be used on complex projects but complex computation lends itself less well to frequent change, prototyping and visibility)
• 
  
• Can the solution be delivered in small increments?
• 
  
• Does the development have a fixed timescale?
• 
  
• Can the requirements be prioritised (can't all be must-haves)
• 
  
• Will users be able to define requirements interactively?

Of course some of these questions are important in a non-agile approach too. But these questions are even more important for agile projects.

If you're thinking of using an agile approach, YES to the above questions is good :-)

If you have a few NO's, this doesn't mean agile is inappropriate, although you should consider how you might mitigate these risks.

If you have lots of NO's, you should think seriously about whether your project is really suitable, or ask yourself honestly, is your organisation really ready for agile?


See also:
10 Key Principles of Agile Software Development
10 G