I have been involved in other Data Modelling projects where intense analysis was done to try to understand all the intricacies of the data before the application development started. This analysis sometimes lasted 3 months, 6 months, or even years. It goes without saying that this is not an efficient was to organize a project.

If you try to segment application user stories, individual reports, and data requirements as stories they end up being a bit too fine-grained from database point of view. Creating a data model from a single user story or report can lead to a data model that has to undergo a great amount of re-factoring as new user stories, reports, and data requirements are considered. Frequently a new user story that enhances application functionality requires an entirely different data model.

Then I started to think that this can happen to most Agile projects. They slice the User Stories thin from an application point of view and that works as the application components can be somewhat independent, but what happens when you try to line-up the data components?

I am sure this impedance has led to the more drastic database re-factoring that has caused it to have a bad reputation and caused people to write books on the subject.

Epiphany

Then it hit me. Although the User Story Mapping exercise does allow for an end to end view of the application that can then be iterated on, it does not create an end-to-end view of the Data Model or the Data Domain. In fact, some critical components of the Data Model may not be encountered until much later. This can cause significant rework based upon the design that has been done earlier.

So what could be the solution?

Agile Enterprise Data Model

An Agile Enterprise Data Model is a thin data model of the Data Domain that can be done as a two-week technical spike. This Agile Enterprise Data Model provides a User Story Map for the data. It provides a Data Model with placeholders for discussion and further refinement. The concept it not to do detailed Data Modelling but to understand all the data components at a high level that will need to be considered by the project. Used in conjunction with a User Story Map, it can be a valuable tool to allow the application and data model to be worked on in true iterations.

Typically an Agile Enterprise Data Model is a conceptual data model with 20-30 entities. There are minimal attributes and discussion and understanding revolves more around entities and relationships than anything. The Agile Enterprise Data Model can then be refined to create the application database, Operational Data Store, and Data Warehouse.

Summary

I have used the Agile Enterprise Data Model with very good success. It also works best in a Data Domain you are unfamiliar with as it allows you to understand a Data Domain holistically initially and then deliver in iterations. The best of both worlds.

Context

I work for a company that bids competitively on projects against other companies. In almost all situations we have to create estimates to provide to the client or else we would not be successful in winning the business. So estimating really is a fact of life for the type of business we are in. Although it might be nice to proceed on a project without an upfront estimate, that really isn’t a luxury we are provided. I believe we are in a similar boat to the majority of people out there.

The Practices

Over the past 20 years I have honed my estimating skills with the experiences on projects. Over the past 6 years, this estimating has been predominantly for Agile projects. Although we have not been perfect in my estimating, I am quite proud of our track record and feel that we have been correct far more than we have been incorrect. Where we have been incorrect, we have augmented the estimating process so we won’t be incorrect in that way again.

The practices are not in order of priority as I had a real problem trying to do that as I think they are all important. So without further ado:

1) Remember to estimate Project Management and Technical Management

We frequently ran across missing these factors on early estimating attempts. This is usually done by everyone as they work on estimating as the work is easy to forget. It is a critical part of the estimate to ensure that these estimates are included so that we don’t scrimp on these tasks and cause larger issues for the project.

2) Don’t plan on your Technical or Application Architects being any more than 20% on construction tasks

This one continues to plague projects I estimate. No matter what the work is, the Architects will always want to work on their fair share of construction tasks. It is a noble desire and will return great benefit if they can work more on construction tasks. But I wouldn’t bet on it. In fact, I would even consider reducing this to zero depending on team size and complexity of the solution. If the Architects can work on more construction tasks, just consider that a bonus.

3) Remember to estimate for meetings and other factors in your schedule estimate

OK, now you have the estimates so lets just plan the hours out on the calendar right? Not quite. Remember to reserve some time every day for meetings, stand ups, and other non-construction activities. In addition, remember to plan for at least some time for vacations, holidays, and sick time. Use your statistics from your company to generate a rough factor for the project. It will just reserve a percentage of your schedule at the start, but then you will have the wiggle room when people start dropping like flies during flu season.

4) Hold a risk workshop and include the weighted estimates in the overall estimate

Mention Risk Workshops and most people yawn before you have completed the sentence. But they have great value. They are a great team building exercise at the start of the project as well. But ultimately, the output from the Risk Workshop should be used to generate an estimate and apply that estimate to the overall project estimate. By calculating the impact and probability of Risks occurring you will generate an estimate of the Risks that will likely occur. My experience is that if you don’t include these estimate, you will frequently address these risks occurring with Change Requests. The project can be much smoother if the estimate are included up front and you don’t surprise the clients. Yes, we won’t know all the Risks at the start, but it is better than assuming there are no risks at all. As Dr. Phil says “How is not estimating any Risks at all working for you?”

5) Estimate at multiple levels and triangulate

Probably the most important practice. We never just create one estimate. We typically estimate bottom-up (object level), deliverable (mid level), and top-down (schedule level). We use metrics for the bottom up and mid level estimates. (how long does a simple CRUD screen take, moderate report, etc..) Then we compare all three estimates and rationalize the differences. It is amazing how this rationalization uncovers estimating oversights.

We also then use Planning Poker sessions as we execute the project to confirm requirements and plan our iterations.

6) Proactively get information required to provide an estimate

Many times there are factors that may cause the estimate to change greatly. (Data Conversions, Legacy interfaces, unknown technology) Ask these questions early on and factor them into your estimates.

7) Say No when you don’t have information to provide an estimate. But be proactive and say what you need to provide an estimate.

If you don’t have the required information to properly estimate, then don’t. But don’t just say you can’t estimate. Provide the details of what information you need to be able to provide an estimate. I know on past projects we have guessed many times on estimates where in hindsight, the client would have gladly provided all the information we required.

8) Track estimates and actuals and use the metrics for future estimating. (both within the project and for future projects)

Yep. We need to track estimates. Sorry. These metrics will then be used to determine on average how long certain objects will take and the percentage that certain areas of the project will require. (Like Project Management!)

We also hold retrospectives and review iteration estimates and actuals so that we can revise our estimates as soon as possible within the project and taken them into consideration for future iterations.

9) Factor educated contingency into your estimates.

We have 17 contingency factors (and counting) that are weighted and applied. (at the team’s discretion) If nothing else, it is a least a checkpoint for the team to think about whether certain situations exist that may affect estimating. (new team? data conversion? new technology? complex interfaces?) Don’t just apply a standard 10% blindly to estimates. It has to be based on reality.

Like Risk, these contingency factors should then we applied to the estimate. I would also recommend that you don’t show what part of the estimate is Risk versus Contingency versus base estimate. Clients will then say that the contingencies won’t happen so just subtract that estimate. <sigh> The estimate is holistic.

10) Execute in a manner that respects that estimates are not actuals. They will be incorrect.

And after all the estimates are done, don’t execute in a manner that makes Captain Bligh look like a level fellow. Don’t micro-manage, realize that these were only estimates – some will be higher and some will be lower. Very rarely will any be totally correct. Let the clients trade requirements and stories as priorities change! You could not possibly know all the scope up front. But also don’t just agree to add new scope. A lot of issues about estimating do come down to good old-fashioned scope control. The estimate should be a guide and a placeholder for a discussion, not a roadmap.

Summary

My experience is that is we do all of these practices, our estimates will still be wrong. But much less wrong. More importantly, these practices help us to discover better ways of estimating. Discovering better ways doesn’t only apply to development practices, but all project practices. Ultimately these estimates also help the team members to feel better about their work as well. No one like to miss estimates and managing projects in a manner that respects that the estimates are not actuals will alleviate many of the negative connotations with estimates.

<SoapboxMode>

The correct thing is to fix how the estimates are managed, not to stop doing estimates.

</SoapboxMode>

P.S. I forgot one! Here is a bonus practice 11) Estimate that you will be wrong – remember to estimate for refactoring, defect fixing, and some rework. We are all good, but not that good.

Re-posted from http://bornagainagilist.wordpress.com

Before I proceed, let me just review my definition of Optimal and Sub-Optimal Systems:

Project Value Stream

Agile has rightly focused on the Project Value Stream and I don’t believe anyone would argue that the Project Value Stream is maximized when executing the project in an Agile manner. But by optimizing ONLY the Project Value Stream, have we sacrificed other Value Streams?

What about the value external to the project? What about the Program and Company value?

Program Value Stream

If I follow Agile by the consensus of opinions I hear proposed most frequently, the following two types of project information are lacking:

Project Memory – Information about how the project was planned and executed.

Solution Memory – Information about the technical or functional solution for the project.

If I use User Stories on stickies, manage via a Kan Ban board, and my retrospectives, application and automated test cases are primarily my documentation at the end, can I answer the following questions?

1. How can I search prior projects for leverage opportunities? Must I read through the code and tests and somehow determine leverage opportunities?
2. How can I review prior projects history for a history of how estimating worked so my estimates can be better this time?
3. Since we acknowledge that I there is never enough time to create all the automated test cases, how do I know if a new requested change is implementing behaviour that is beyond the intent of the application and will cause downstream effects that I can’t anticipate because we don’t have an automated test to ensure its correctness currently.
4. How can I ensure my solutions are consistent across projects if they don’t have high level knowledge of each other?
5. Do I have adequate documentation to maintain these applications for the next 10 years if I have a complete turnover in employees?
6. How can I manage a department where the reality is that many people will not be able to be dedicated for the lifetime of the project? Do I require more documentation in a situation like this?

By it’s very nature, Agile Software Development projects are silo-ed projects with primarily full-time members and with little governance breaking down the barriers between projects. This causes an even greater need for attention to the Program Value Stream.

Company Value Stream

Perhaps one of the most troubling trends lately is the statement that estimates should not be created anymore as they are bound to be wrong and a waste of time. It is proposed that the project should be started and after two or three iterations the project will be able to confirm the velocity and inform the client as to an accurate estimate on what it will take to complete the project.

This statement is from the point of view of the project entirely. Every project that starts needs to be backed with a business case that confirms that for $X I will return value Y and that is acceptable to the business. If we are not estimating projects anymore, we run the risk of initiating the wrong projects and wasting project money until we determine that the project will either spend too much money or return too little value.

Stating we don’t need to estimate is ludicrous if we truly care about the long-term viability of the company. Implied in my statement is my belief that User Story Points must be translated to hours. In discussions I have had with developers, they have asked for the hours for each User Story as a means for ensuring they were on track. (when I didn’t provide it, they did the math themselves)

Although I like the use of User Stories and User Story Points to estimate, if we do not translate the User Story Points to hours we are Sub-Optimizing. We are placing the development process ahead of meeting the business case. By not giving the developers the context of the estimates in relation to the project’s business case, we are creating a layer of isolation between the business case and the programmers. We are making the project iterations more efficient, but also possibly sacrificing the ability to meet the business case.

And isn’t the business case the reason the project exists?

Three ways to ensure your Agile Project is not Sub-Optimal

1. Estimate your project – Make sure you estimate your project and ensure that estimate is incorporated into the Business Case to validate the project raison d’etre. These estimates must be given the care and attention they deserve and not just estimates for the sake of getting the project approved. My recommendation for how to estimate an Agile project is a topic for another day.
2. Create Lightweight Solution Architecture Deliverables – Ensure that your project defines the Solution Architecture at a high level and everyone shares that vision of the solution. These deliverables can then be used for project governance and for ensuring consistency and leverage opportunities across projects in a program.
3. Translate User Story estimates to hours and track your time – User Stories being translated to hours sets the duration expectation with developers and also provides context back to the business case to ensure we are on track. Tracking time, the bane of everyone’s daily work life actually does have great value for the program and company. Although knowing a project velocity is a great predictor and planning tool, it doesn’t let me know the following:

• What types of work do we estimate poorly or take longer than expected?
• What types of work do we estimate well or take less time than expected?
• What types of work do we forget to estimate?
• What issues do we encounter that add to the time in take to complete a task?

Summary

“Are we sacrificing long-term Enterprise objectives by developing projects in an Agile way?” I don’t believe that anyone argues that Agile is not the best way to execute a project. But I do think that sometimes Agile’s sole focus on value for the project and the client within the project may cause us to lose focus on the value the Program and the Company requires.

We need to ensure we keep the entire value stream in mind when we are optimizing processes. Otherwise we will have a string of very successful projects at a number of failed companies.

Re-posted from http://bornagainagilist.wordpress.com

Definition

There is an excellent website that provides some great information on Pretotyping. The site is www.pretotyping.org. The definition of a Pretotype that is proposed on the site is:

My Pretotype experience

So now that we can see the connection between Agile, Lean and Lean Start-ups, and Pretotyping, what was my experience with Pretotyping?

1. A Pretotype is an incredibly valuable tool to be able to design and perform analysis on the large rocks of value for a project and solution without having to get drawn into details. It was a great tool to stay grounded in what value the client would realize as opposed to the colour schemes, particular fields, and other minutiae.

2. It is difficult to communicate to the client and gain agreement as to where exactly a Pretotype will stop and where Prototypes and other deliverables will continue. Although we tried to state as clearly as possible the boundaries, people are used to Prototypes and find comfort in the detail that exists in Prototypes. My only suggestion would be to continue to over-communicate and continue to discuss the differences between a Pretotype and Prototype. My other thought would be to use the actual term Pretendo-type to more overtly communicate the purpose of the Pretotype. (Some people may assume a Pretotype is a Pre-Prototype, while it is a totally different animal)

3. Although the Pretotyping proponents talk about the ability to use paper and other deliverables for the Pretotype, our clients required a technical experience to allow them to interact with the Pretotype in a manner that is similar to the potential end state. The good news is that there are plenty of great tools out there to create Wireframes that can be used to create Pretotypes. Be careful though, the use of these tools can increase client expectations as to how far the Pretotype may go towards being a Prototype.

I ended up using Iplotz as my Pretotyping tool and I was very impressed with the tool. It was very easy to use and also allowed for the all the functionality I required. Iplotz has both an online and disconnected mode. Iplotz also allowed me to group all my Wireframes into a project and let people collaborate of the project. The suite of controls was also very extensive. I have heard great things about Balsamiq as well. There are a multitude of other solutions as well. I encourage you to review the options and decide for yourself which fits your needs the best.

Summary

Pretotyping has definitely found a permanent place in my Agile toolkit. It won’t fit for every project and client, but I believe it will be something that I will use more often than not.

Re-posted from http://bornagainagilist.wordpress.com

How do I define the two?

Agile Product Management : Typically the project team is producing a product. A product can be defined as a solution that either is being sold to multiple clients or has the potential to be sold to multiple clients. The time horizon for the work and decisions are more future thinking and longer term as value is always based on increasing the potential for multiple sales.

Key indicators: Stakeholders include end clients and product company team members that are not part of the development team. There may not be a formal contract or Statement of Work.

Agile Project Management : Typically the project team is producing a solution to address a specified business need and address a business case. Many of the decision may need to be tempered to ensure the project team can make current commitments. Focus is less on future thinking and more on current commitments. (although not totally ignoring the requirement to have the solution to flexible in the future)

Key indicators: Stakeholders include end clients and project team members. There is a formal contract or Statement of Work.

Agile Product Practices

The practices that are somewhat more aligned more with Agile Product Management than Agile Project Management are:

• Minimal documentation outside of User Stories and executable Test Cases
• Absence of formally defined  scope
• Absence of estimation of scope

Although these practices can be minimized or eliminated for Agile Product Management, it is not realistic to expect the same for Agile Project Management. When working with clients on Agile projects, there are certain constraints that clients operate under that may not allow for these Agile Product Practices to be used.

I believe we need to start separating our Agile Practices into the two camps to start to discuss which practices work best in each. If we don’t do this we risk having Agile Product Management that isn’t as Agile as possible, and Agile Project Management which takes on excessive risk by trying to apply practices that may not be the best fit.

My perspective is always more on the Agile Project Management style as that is the circumstance I encounter the most in the engagements I have.

Re-posted from http://bornagainagilist.wordpress.com

All the people that attended had never done Silent Brainstorming before.

Here was the agenda for the session:

Two Things – This is a very quick Silent Brainstorming warm up activity where we ask the participants for two things about the proposed solution. One thing that the solution MUST do, and one thing the solution MUST NOT do. This was a good warm up session and quite well received.

Who/What/Why – Silent Brainstorming exercise to start to get everyone to think about Who is going to use the solution, What are they going to do, and Why are they going to do it. Very good exercise and the group started to build up momentum and throw out a lot of ideas. We had an excellent diversity of styles and opinions in this group. Very nice to have and it is making this session very productive. We also had a good diversity in the two facilitators. My co-worker has more of a Business Performance Consulting focus while I have a technical background. I think this is an excellent match and allows for us to ask more of the right questions.

Personas – We take a break from the Silent Brainstorming and have an interactive session on the Personas or people that will use the solution. While we did not capture all the attributes about Personas that would normally be done in a standard Persona session, it was still a very valuable session. This session generated the most discussion and new ideas of any session. The amount of information we captured on the separate Personas and how they would use the solution was incredible. We easily captured at least 4-5 new Personas and ultimately functions of the solution that we were totally unaware before we started. Easily the best session. I think varying Silent Brainstorming with Interactive Sessions also helps to generate more feedback. Need to remember this.

User Story Mapping – The last Silent Brainstorming exercise was a User Story Mapping exercise. This exercise generated some excellent new ideas on what the solution needs to do. I think this session really benefited from having the three sessions held previously. With the results and discussions from those three sessions in hand, people were able to come up with the User Stories very easily. If anything, we had to end some discussions prematurely due to running out of time. It was fantastic to be in a 3 hour meeting where people are passionate and energized to continue talking. I’ve seen User Story Mapping sessions take 20 minutes. Everyone had their stories up in 5 minutes.

Summary

I’m an Innovation Games convert. It was a great session and we captured much more information than I had hoped. We have a larger group schedule next week and I am very excited about the information we will gather from that session to combine with this one. If you haven’t checked out Innovation Games online, I recommend that you go there and try out some games as soon as possible. You won’t be disappointed! Don’t be afraid to customize then to your specific circumstance….

Re-posted from http://bornagainagilist.wordpress.com

Overall

The games were met with a good level of skepticism and optimism. The group was about 20 people very familiar with different types of Silent Brainstorming. So they were not new to the method or process. They was a lot of feedback and ideas generated and at the end of the day we generated the initial problem statements that the session was intended to generate.

Overall, I’d give the session a B+.

Whole Product Game – The game was a great, repeat great, ice-breaker. It really worked well as an introduction exercise to get everyone thinking about what the company is and what the clients expect from the company. I would definitely use it again. Solid B.

Company Report Card Game -Probably the best game. People really liked the metaphor about being able to grade areas in addition to stating what was working well and what could be improved upon. There was some discussion on whether we needed guidelines for the letter grades. At the end, I think I am comfortable that we don’t need guidelines because it isn’t the absolute grades that matter. Rather, it is the relative grades of each area that are important. By looking at these relative grades, it becomes quite apparent what areas people think are the highest priority. I also created a plus/minus score for each area. (Good old Canadian hockey influence) The plus/minus just tracked the votes on positive items minus the votes on items needing improvement. Another data point that indicates where people believe there is a problem. The relative grades and the plus/minus scores were very consistent. Solid A.

20/20 Game – We adapted quickly and did not do this game as we were running out of time. I’d still like to try this game and maybe the next time we can see about the feedback we can gather using this game. No Grade.

So overall, I feel it was a very good session and I looking forward to more chances to play games at work.

Re-posted from http://bornagainagilist.wordpress.com

Strategy Meeting

In the Strategy meeting, we are using three different and customized Innovation Games. We were going to take a somewhat traditional approach to this Strategy session until we sat down and thought about the process we should use to present current state. The question was then asked about whether we should present on current state, or let the group tell us what the current state is from their perspective. We loved the idea. Instead of he traditional approach of presenting the opinion of what current state is, why not get the team to create the current state through Silent Brainstorming. We were assuming that everyone would agree as to what the current state is.

So the three games I am proposing to get us to review current state and start to think about Strategy are:

Whole Product Game – To get us to start thinking about current state, we are going to use a slightly altered version of the Whole Product Game. It will be changed to solicit input on the entire company rather than a product. I believe this game will provide some interesting insight as to what people view as the company’s differentiators.

Company Report Card Game – I based this game based upon the ‘Grade a Feature’ Exercise. I believe the grading metaphor is something that we all can relate to and can allow for excellent insights. Instead of grading features, I have customized the game so that we will be grading the company according to the following categories:

• Locating Opportunities (Sales)
• Satisfying Opportunities (Offerings and Products)
• Delivery Opportunities (Delivery and Manufacturing)

For each category a person will do the following on a stickie:

• Provide one overall grade per category on how they think the company is doing in that category – denoted by circling it
• Provide an item or items which they feel the company is doing well in that category – denoted by a plus sign in a circle
• Provide an item or items which the company needs to improve to be able move up to the next higher grade – denoted by a minus sign in a circle

20/20 Game – I based this game on the 20/20 game contained in Luke Hohmann’s excellent Innovation Games book. There is also an excellent website available with online games. (although the 20/20 game is not one of the online games) This game will be based upon the results of the Company Report Card Game and each person will be asked to asked if the company is better or worse for each of the items that came out of the Company Report Card Game as compared to two years ago. This will be done by using stickers for voting. Each person will get 5 green stickers for voting for the items the company has improved and 5 red stickers for voting for items the company has  regressed on.

I’m very excited to gather the groups ideas and also for the ability to capture trends.

I’ll save the Rapid Discovery Innovation games I will be using for my next post…

Re-posted from http://bornagainagilist.wordpress.com

I was encouraged recently when I was re-reading information on Feature Driven Development, but I found that there was much there that I did not believe in. The concept of creating an overall model in Feature Driven Development is one that I do not see referenced in many other methodologies. I believe this concept of creating an overall model before starting iterations is absolutely mandatory. But I do believe that the additional practices of creating detailed domain object models in Feature Driven Development is excessive and not required at the start of the project. It seemed to me that Feature Driven Development still required considerable big design and requirements up front.

Solution Driven Development

I believe in what I like to term Solution Driven Development. If you can’t or haven’t envisioned the solution, how can you start executing the project? Some people would say that not having to envision the total solution is Agile. I believe it is unprofessional and lazy. Some would say that the solution will change anyway so why spend the effort envisioning and planning when it is likely to change? I believe that we can’t proceed unless we have a shared vision on what we are creating. 

Let’s start with the definition of Agile Software Development:

“Agile development is a style of software development that emphasizes customer satisfaction through continuous delivery of functional software. Based on a variety of iterative development disciplines including extreme programming (XP), agile methods put developers to work in small teams to tight budgets and short timescales. In contrast to traditional software development methods, agile developers liaise continuously with business clients, aiming to deliver working software as frequently as every two weeks during a project, and welcome changes to the requirements in response to evolving business needs.”

I believe the key is this phrase: “welcome changes to the requirements in response to evolving business needs”. This sentence has the following two assumptions:

1. “Changes are welcome to the requirements” – This means we know what the baseline of the requirements are. Otherwise, how could we know what a change is?
2. “Respond to evolving business needs” - We are responding to evolving business needs. This assumes that we have a baseline of current business needs.

What I consider Solution Driven Development satisfies these assumptions.

Solution Driven Development

1. Creation of an overall model of the solution via consultation and collaboration with all of the stakeholders
2. Creation of a high level features list that are then scheduled in Iterations
3. Creation of User Stories that define the features. The creation of these User Stories are only done for the next 1-2 Iterations.
4. Iterations then refine the design, development, construction, and implementation of the solution.
5. The solution is tested using the practices of Test Driven Development and Behaviour Driven Development.

If an Agile Project lacks an overall model for the solution, I would propose you are doing Ad-Hoc Software Development not Agile Software Development

Re-posted from http://bornagainagilist.wordpress.com

If you listen to some Agile proponents out there you might think that Agile projects do not have a planning phase. You may have heard the following:

• You shouldn’t create a plan as things will change and it will be wasted effort.
• You shouldn’t create estimates as they will just be wrong and it will be wasted effort.
• You should just start executing iterations and you will then determine your team’s velocity and what you can achieve.
• You just keep on working on prioritized stories until the client tells you to stop or runs out of money.

As long as we are doing Agile projects we must first remember what a project is. A common definition is:

“a task or planned program of work that requires a large amount of time, effort, and planning to complete”

So really, any work cannot be termed a project without a plan. I would also add one additional criteria to what comprises a project. I believe a project requires two key criteria:

• A plan that defines scope, cost, and schedule. (At whatever level deemed appropriate)
• A vision of the solution that defines success for the project sponsor and the project team.

Too often I feel that projects are started without the vision fully crystalized. If there is not a vision of the solution, how can the following be determined?

• How can the project team be sure the solution truly solves the business problem
• How can the project team be sure that the solution is functionally and technically cohesive, consistent, and correct
• How can the project team be sure that the project budget and schedule can deliver a solution that satisfies the minimum client success criteria?

Without taking the time to confirm the vision of the project we are risking the success of the project.

Kan Ban boards are not the Plan

What made me think about this? I have seen more and more Kan Ban boards which people use as the project plan. Kan Ban boards are intended to be visibility into the project plan and status, but should not be the project plan itself. There needs to be a plan outside of the Kan Ban board that defines the project plan with some amount of dependency management. In addition, a separate vision of the solution should also exist. (Both functionally and architecturally)

Without these two artifacts I would suggest that you may not have an actual project and your Kan Ban board may simply be stickies on a wall.

So how do you plan an Agile project?

Now I am not proposing a detailed work breakdown structure for an Agile project. I believe there are lightweight methods that can provide the value for minimal cost. I typically plan an Agile project in the following 4 ways.

1. Ensure that Project kick off, Charter, and risk sessions are held. These are very short meetings but start to ensure that all team members share a common understanding of what the project is expected to achieve.
2. Hold a Rapid Discovery Event to confirm the scope, objectives, and high-level plan of the project. This session should  take only 1-2 weeks for a 3-6 month project. This event is critical to build a common understanding of the vision and solution.
3. Create and estimate the project schedule at a deliverable-level with dependency management to ensure that the project can deliver the minimum client scope, budget, and schedule requirements
4. Gain agreement from the client as to how the Agile project will be run and the ‘rules of engagement’. We have already confirmed we think we can deliver the minimum functionality, so this meeting is focused on gaining agreement on the process of how we will work together to deal with change.

I’m not proposing a detailed project plan, requirement document, or architecture document, but a little work on all three can go a long way to ensure success.

Re-posted from http://bornagainagilist.wordpress.com