Why Developers are More Productive When They're NOT Programming.

Executive Summary:
Having your development team involved in strategy sessions, requirements gathering activities, and operations shadowing, will greatly reduce defects, reduce total project costs, and improve your overall delivery times.

Image Source: Photobucket.com

When I started out in technology, I worked for one of the Big 4 systems consulting firms (previously the Big 8 at that time :).  Our projects were generally made up of 40 – 50 team members with about 2/3rds of the team involved in actual development activities. These projects lasted a long time and demanded a lot of hours.  Sitting behind our terminals in rows of office cubes, one of the running jokes we had was that it felt like being on a Viking ship with everyone rowing as hard as we could, while the task-master, our project manager, cracked his whip and bellowed, “Keep coding! Keep coding! Keep coding!”.

Can you picture it? We did, all the time. I honestly don’t recall hitting many of our deadlines or getting much of our work into production, but I do recall spending a lot of time dealing with endless bugs, the majority of which were not related to broken code, but rather code not meeting the actual requirements.

One of the biggest takeaways I had during this period, was how management assumed that the more time we spent coding and testing (QA), the faster we would reach our goals.  Yes, we billed our clients by the hour, but I don't think that was completely management's  motivation here.  As opposed to generating tons of hours on something that never seemed to get done, our direct management would have much more prefered we completed our work, and on time, so that our clients would be happier and provide even bigger and better things for us to work on.  We all wanted the same.

Having run the gamut of SDLC roles as a developer, an analyst, and project manager, I gained a greater and greater appreciation for agile processes and techniques, but also realized that as vital as handing off stories to the development team for coding and testing were, there were several activities that developers could do to be even more productive and improve the success rate of our projects; and none of these involved doing the actual coding and testing.

Here are a some of the lessons I learned:

1) Have developers attend business strategy and requirements sessions
With advent of lean and agile development techniques, it seems like we are doing this already. For example, in SCRUM, we include members from both the technology and business/product teams in sprint planning and release planning sessions.

While I agree with this approach wholeheartedly, a big issue that often crops up here, is that by the time we reach this stage, and by design, developers get a very narrower view of the requirements, often insulating them from big picture objectives. When developers lack the big picture, it often leads to potential misunderstandings resulting in product defects that aren't caught until QA steps in.

One way of mitigating this, is to involve developers in the strategy and requirement sessions. In the same way that some business team members attend sprint planning sessions, and are generally asked to just observe, why not allow and encourage your development team members to follow the same protocol in business strategy and requirements gathering meetings and sessions?

By including your development team members in requirements gathering meetings, strategic planning sessions, and meeting with business subject matter experts, developers will gain a better understanding and broader context of the project and the organization's business objectives. I'm not suggesting your entire development team run around and attend every strategy and requirements session, but where feasible, encourage them to attend a broad spectrum of these and try to have at least one development representative.

Your development team's exposure to these meetings also provides the opportunity for minimizing future technical-debt. A broader understanding of requirements scope can result in catching design decisions earlier that would have resulted in solutions architectural impacts further down the road. Developers with more insight into the overall process and objectives also gives them greater ownership of the solution and the ability to suggest more effective and far reaching solutions than may have been thought of before.

2) Observe the Actual Business
Your development team should also have the opportunity to visit and/or observe the area of the business that the project is serving.  One of the clients I worked with had service representatives run delivery routes to load and unload their product from city wide distributed kiosks.  Having rode along with one of the reps during a very frigid winter day in Chicago, I noticed that there were several tasks that required them to remove their gloves, not only slowing down the process, but making it very uncomfortable for the rep.  Since that ride-along, every time I attended process and interface design sessions, I couldn’t help but think how cold it could get, and how important it was to make any new process, user interfaces, and new hardware reconfiguration, as fast and easy to interact with, and be able to perform as many of these tasks as possible while wearing gloves! Doing so would make the reps happier, more efficient, and benefit the business to boot. A win-win.

3) Business Analyst Pairing
Analysts do the best they can to capture and write complete and accurate sets of stories and user acceptance tests. But analysts are human too, at least most of them. Requirements get missed, are sometimes written unclear and/or inaccurate.  By pairing one or more developers with a business analyst during the initial requirements gathering activities, developers can get clarifications on business processes even before any release or sprint planning sessions, provide a safety check on what's actually captured, and have someone to reach out to whenever they have questions.  This also enables your development team to more readily question and challenge requirements during sprint planning, potentially catching incorrect or nebulous requirements before they get into the code.

In Steve McConnell's Code Complete, he found that reworking defective requirements consumes 40-50% of the total cost of a [software development] project. And that.. the earlier a defect remains undetected in the development process, the more expensive it become to correct [Figure 1] .

Figure 1 - Code Complete: Cost of Defects Introduced Vs. When Fixed

Even more striking, McConnell found that 60% of all defects exist by design time.

In other words, at the time the requirements are being translated into a design, there are already significant defects. Meaning, the requirements themselves are inaccurate and/or the translation of these requirements is inaccurate.

It seems obvious, but as a developer, being involved in the requirements capture process and having a better understanding of your requirements by design-time, rather than waiting for QA to validate them, will greatly reduce your project's duration and overall cost.

Studies from McConnell book also found that every hour you spend on defect prevention will reduce your repair time from three to ten hours. That's a pretty big savings!

While we tend to think of software projects as a lot of people sitting around and coding, if we are truly agile, we want to ensure we place as much value on defect prevention activities as we do on the actual product creation activities.

But what can be done if your development team is NOT or will not be involved in the business requirements gathering processes?

Three additional impactful methods for defect detection are design reviews, code reviews, and mockup/prototyping sessions.

Design Reviews  are early stage team presentations/reviews of how the solution will be designed to meet the business requirements and comply with established project design standards. 
Code Reviews are on-going informal reviews via pair programming and/or formal code reviews to ensure the code meets the business requirements and complies with the project development standards.
Mockup/Prototyping Sessions - A method for technical and business teams to review product requirements together via the use of low to medium fidelity mockups/prototypes.

According to McConnell, formal design reviews, code reviews, and prototyping, can each detect between 35 – 80% of defects (Figure 2).  But even more effective, by combining all three of these methods together, defect detection dramatically increase to a rate beyond 90%!

Figure 2 - Code Complete: Defect Detection % by Detection Technique

Values are High to Low Range & Average.

Even with great processes in place like SCRUM, if we continue to rely on QA to iron out all of our issues on the back-end, we will end up sailing into some very stormy weather.  Including developers in strategy meetings, involving them in operations, pairing them with analysts during requirements gathering sessions, and incorporating design and code reviews, are relatively easy ways to minimize the defects before they get to QA.   Although a little more time consuming, implementing prototyping sessions is another great way to bring both the business and tecnical teams together to clarify requirements and reduce defects.  And by combining multiple approaches, overall projects costs and delivery time can be reduced significantly.

I recognize how hard it is to change the mindset, structure, and processes of an organization, but if we truly want to be agile, we need to be open about the range of activities team members are involved in and can be involved in.  Don't be afraid to experiment, this is the purpose of retrospectives, just be sure to try things incrementally.  Not everything  you try is going to be a success, but those that are successful will propel you further and farther to a better place.

So, the next time you feel like you are stuck in vicious circle of coding and testing the same functionality over and over again, just think of that Viking ship I sailed on.

“Keep coding! Keep coding! Keep coding!”.

What methods do you use to eliminate defects and improve your agility? It would be great to hear from you.

Agile Portfolio & Program Management - Part III: Ultimate Agility

Executive Summary:
Using a Kanban board for Portfolio and Program Management can not only provide visibility into your processes, but also provide a path to measure and continuously improve your organization's agility.

This is the last of a three part series on Agile Portfolio & Program Management.  In Part II of this article, we discussed how a Kanban board can be applied to Portfolio and Program Management Ideation to both encourage agility while still providing oversight and governance. If you haven’t read Part II, I suggest going back and reading it first prior to this article.

In the last installment of this series on Agile Portfolio & Program Management, we are going to discuss the final validation activity, High Level Analysis, and the process prior to project launch, Project Preparation. We will also put everything together and demonstrate how a Kanban board can make the whole of a process greater than the sum of its parts. Let's get going!

Below is the basic Portfolio/Program Management Ideation process we defined for collecting, validating, and preparing ideas for implementation. Note that we included three validation gateways within the validation stage to ensure organizational alignment prior to the launch of complex initiatives.

Figure 1: Portfolio & Program Management Ideation with 3 Validation Gateways

Translating the Ideation Process to a Kanban Board
Here is how we modeled the activities of the the first stage, on our Ideation Kanban board so far.

Stage 1: Capture

Figure 2 – Kanban Columns for Idea Capture

Ideas are collected in an Idea Queue or Backlog, selected and prepared by the queue's Portfolio/Program Management product owner, where they are then scheduled for the Initial Evaluation. To learn more about the Initial Evaluation of an idea, refer back to Part I of this series.

Our ideation cards contain the following attributes:

Figure 3 – Sample Ideation Card

Card data is filled out as it moves through the ideation process.

To this point, we've discussed the first two Portfolio/Program Management gateways, the Initial Evaluation and Business Case Review.

We'll begin this discussion from the assumption that the idea passed the initial evaluation, the business case review, and that the ideation card was moved to the "Ready for High-Level Analysis" column of our Kanban board to indicate that it is now ready for High-Level Analysis.

Stage 2: Validate - High-Level Analysis
Here is how we modeled the activities of the the second stage, Validate, on our Ideation Kanban board so far.

Figure 4 – Kanban Columns for Validation

Click Image to Zoom

The Portfolio/Program Management product owner will then prioritize which items to work on next and select a card from the Ready for High-Level Analysis column. Once an idea/initiative is selected, a program or product lead should be assigned to the initiative, along with one more lead business analysts.

High-Level Analysis
High-Level Analysis is a final Portfolio/Program Management checkpoint prior to an initiative's launch.  During High-Level Analysis, the scope, cost, and basic roadmap of the the initiative will be defined and the reviewed one last time by the Portfolio or Program Management team prior to launch.

This analysis has two primary purposes:

1. Provides just enough information to ensure that within the scope of this initiative, we are implementing the right things at the right time, and doing it within mutually agreeable budget.
2. Provides requirements that can be dovetailed directly into our agile implementation process.

When analysis begins, one of program or project leads can move the card into the In-High-Level Analysis column of the Kanban board to indicate analysis is underway.

High-level analysis will generally consist of the following:

• Impacted Processes, Systems, & Teams
• High-Level Storyboards - New and/or Updated Processes & Features
• Program/Project Epics & Features
• Initial Program/Project Roadmap
• High-level Cost Estimates

Impacted Processes, Systems, & Teams
Process diagrams help identify the scope of the project, along with helping to uncover impacted processes & systems.

If you don’t already maintain business process diagrams, they are severely out of date, and/or in a variety of formats, this is a tremendous opportunity for your organization to begin identifying a standard approach to modeling your business processes, technical infrastructure, and establish a definitive point in time to maintain them. Doing so, also gives you more reason to maintain them in a central repository.

Updating your process models at a consistent point in your development process, may not get every business process looking the same, but it will begin to normalize the format of these models, ensure a common location for storing them, and more importantly, identify gaps where these processes have never been fully modeled before.

More on process diagrams: 
Over time it you will find it easier and easier to perform impact analysis as your models become more current and there is less need to create these models from scratch. If you are looking for a process model standard, I recommend using BPMN 2.0 event process chains. Event process chain diagrams are extremely powerful and easy to read once you get the hang of them.

High-Level Storyboards
Some basic storyboarding can also be used to identify new and/or impacted product features and provide an idea of how they are expected to work.  David Hussman of DevJam has some great intro videos to storyboarding as well as other related techniques.  If the initiative requires a graphical interface,  consider supplementing your storyboards with basic UX designs.

Program/Project Epics & Features 
As part of your high-level analysis, you should be able to identify your highest valued epics and features.  There are various methods of doing this, but one method for this is the weighted-shortest-job-first approach or WSJF. For more information on WSJF, check out my article, 5 Steps for Using SAFe’s Weighted Shortest Job First Ratio (WSJF) for Backlog Prioritization,  on this topic.

Spending the time to define portfolio and/or program epics and features should not be throw-away work as they will end up as input to creating a prioritized list of the program and/or implementation team project backlogs. Bottom line, whatever you use for your high-level analysis output format, it should be very close in format to the epics and features that are used within your portfolio and/or program level backlog.

Initial Program/Project Roadmap
One of the core functions of the portfolio and program management teams, is to plan (or roadmap) when certain programs, processes, products, and features should be implemented. The mechanics of roadmapping your initiative and understanding internal and external dependencies would also require a separate discussion, but a high-level roadmap of your program or project is a necessary input to the process to guide release planning and backlog prioritization.

What About Risk Management?
One essential piece integrated into your roadmap, should be your risk mitigation plan.

Risk mitigation can be incorporated into your roadmap in two ways:

1. By implementing items that have the greatest potential to delay your project as early as possible.
2. As epics and features in your backlog no different than any other epic and feature except that they are identified as a risk epic or feature.  They are simply work that needs to be performed to reduce the risk of delay and or cost in your roadmap.

High-level Cost Estimates
Now that we have a better handle on scope, we should be able to provide cost estimates with a higher level of confidence than those provided with the original business case.  For extremely large efforts, consider only providing estimates no more than a year out at a time.  Agile budgeting requires a separate discussion, but the main objective of your budget should be to to ensure you are delivering the highest valued items of your initiative within the time and budget available to you, not committing to a definitive set of requirements within a specific time and budget constraint.

Your approach and metrics used for estimation is entirely up to you, but whatever approach you choose, planning poker, an estimation model, or locking your teams in a conference room, involving both technology and business leads during estimation gives key stakeholders a clearer understanding of the project objectives and reduces any big surprises down the road.

Too many cooks performing estimation can be a problem, so choose only the necessary people to be in this meeting. Others can attend, but they should only be observers and not permitted to speak unless there is a dedicated Q&A session at the end.

A Kanban tool can also be used to notify potentially impacted stakeholders of upcoming projects and meetings. For example, notifications can be sent to Infrastructure and Support teams when the status of cards change to a particular value, e.g. a card goes from Ready for Hi-Level Analysis to In-High-Level Analysis. This can alert them to projects coming down the pike enabling them to plan and prepare for according..

After completing an initial round of your high-level analysis, you should have a better handle on your budget, resource needs, the programs, processes, and features you plan to implement, and when to implement them. Once the the program or product lead feels the analysis is detailed enough, they can then move the card to the Ready for Hi-Level Analysis Review to signal your Portfolio or Program Management team to schedule your analysis review.

As with previous reviews, it’s recommended you set these up on a regularly planned periodic basis and make them no more than 1-2 hours.  Product owners, team leads and impacted stakeholders along with a representative from Portfolio or Program Management should be at this meeting.

Standardizing the the high-level analysis presentation materials as much as possible will ensure the presenters knows what is expected of them and your audience understands what they are reviewing.

Ideally, keep each presentation to 30-45 minutes with a 30-45 minute Q&A.  I also suggest letting a present complete their presentation prior to any Q&A or you may end up with a lot of unfinished presentations.

At the conclusion of the meeting, the representative of Portfolio or Program Management will then make a formal go or no-go decision for this initiative.

Similar to how the Business Case Review, if the idea is rejected, the card should be updated with a rejection reason and moved to the Rejected column.  If more information is needed to make a decision, update the card with the information requested and send the card back to the In-High Level Analysis column for further research. If approved, the card is moved forward into the Ready for Project Setup column.

Project Preparation
Finally, when work in the Ready for Project Setup column is ready to be worked on, a designated Portfolio/Program management resource can then move the card to the In-Project Setup column.

Remember that the "Ready" columns should be treated like a backlog and will require someone to be responsible to prioritize and ensure the cards have all the necessary information to proceed.

Figure 5– Kanban Columns for Project Prep.

Project Preparation is the process by which specific resources may need to be procured or configured and/or environments set up prior to moving the work into the appropriate execution team’s backlog. You might even use this point in time to create a collaborative charter for your program or project team.

Collaborative Chartering
Collaborative charters are a great way to kick off a project. These are not the pro-forma charter usually required by executive management that get filed away never to be seen again.  Collaborative charters are generally 1 or 2 page documents that outlines the purpose of the your project, the stakeholders involved, and any working agreements. They get everyone on the same page, literally, and also help when onboarding new team members, to understand the purpose of the project and who's who.  For more information on collaborative chartering, here’s an excellent video by David Hussman on the topic.

Once necessary resources are readied and the work is migrated to the appropriate team backlogs, your ideation card can be moved into the Project Prep Complete column and project implementation can begin as scheduled.  You could keep extending the Program and Portfolio management Kanban boards all the way thru development and even operations rollout, but this essentially completes the Portfolio/Program Management Ideation process, and your card moves to a "DONE" status. I've colorized this column green, to emphasize the process is done and ready for the next stage of development.

The Complete Portfolio/Program Management Ideation Kanban Board

Putting it all together, our Portfolio/Program Management Ideation Kanban Board looks like this:

Figure 6– The Entire Portfolio/Program Management Ideation Kanban Board

Click Image to Zoom

From one diagram, you can see what cards are waiting to be worked on in, what cards have been rejected or approved, what cards are in process, and what cards are ready to be implemented. If you want more information, you can view each individual card for initiative details, decision rationales, and task assignments.

Taking Your Agility to the Next Level

Another benefit of having the Portfolio/Program Management process maintained within a Kanban board, is that it provides a great way to measure the average time each card spends within each activity, as well as the average total time (cycle time) it takes to get from the Ideation Backlog into the hands of the implementation teams. Capturing average activity times and cycle time enables you to identify where you are experiencing bottlenecks, determine the impacts of changes to the process, and provides a measure for your organization's overall agility. Activity and cycle times are measures that all members of an organization can easily understand and can be used a simple way to communicate the overall health of your organization.

To take your agility to the next level, your Kanban board can even be used to communicate status. Imagine the time saved and the increase in productivity by minimizing and possibly even eliminating status reports and status meetings with real-time status and metrics accessible to anyone, anytime.  Doing so, will focus meetings you do have on removing impediments and celebrating victories. And isn't this what agile is all about?!

Using the Portfolio & Program Management Ideation process, we've demonstrated how Kanban can be used to improve organizational agility by simplifying complex processes, providing organizational transparency, and even provide real time agility metrics and a method for status reporting without the status reports.

Now that you have a basic understanding of the power of Kanban, what ways can your organization use Kanban in the pursuit of ultimate agility?

I hope you've enjoyed this series on Agile Portfolio & Program Management as much as I have, I would be grateful to hear you feedback, experiences, insights, and suggestions. Thank you!

Agile Portfolio & Program Management – Part II: Governance

Executive Summary:
Capturing great ideas, obtaining consensus on their definition, objectives, budgets and schedule can be a complex and daunting process within any organization . Using a Kanban board, the Portfolio and Program Management ideation process can be structured to provide organizational oversight without impeding organizational agility.

This article is part of a three part series on Agile Portfolio & Program Management.  In Part I of this article, we discussed how a Kanban board can be applied to Portfolio and Program Management for the capture and approval flow of new ideas and suggestions.  If you haven’t read Part I, I suggest going back and reading it first prior to this article.

Below is the basic Portfolio/Program Management Ideation process we defined for collecting, validating, and preparing ideas for implementation. Note that we included three validation gateways within the validation stage to ensure organizational alignment prior to the launch of complex initiatives.

Figure 4: Portfolio & Program Management Ideation with 3 Validation Gateways

Translating the Ideation Process to a Kanban Board
Here is how we modeled the activities of the the first stage, Idea Capture, on our Ideation Kanban board.

Stage 1: Capture

Figure 5 – Kanban Columns for Idea Capture

Ideas are collected in an Idea Queue or Backlog, selected and prepared by the queue's Portfolio/Program Management product owner, where they are then scheduled for the Initial Evaluation. To learn more about the Initial Evaluation of an idea, refer back to Part I of this article.

Our ideation cards contained the following attributes:

Figure 6 – Sample Ideation Card

Ideation card data is gradually filled in as it moves through the ideation process.

In the Portfolio/Program Management Initial Evaluation, the Portfolio/Program Management Team determined if the idea can be fast-tracked directly to Project Prep activity, or requires a business case developed for further evaluation.

For those ideas that required further portfolio or program evaluation and analysis, we documented the reason within the ideation card, and the card was moved to the Ready for Business Case Development column of the Kanban board.

We'll begin this discussion from the assumption that a business case is required for this idea and a card for this idea resides in the "Ready for Business Case Development" column of our Kanban board.

Stage 2: Validate - Business Case Development

Figure 7 – Kanban Columns for Validation - Click Image to Zoom

Up until now, our evaluation of ideas has required a limited set of data and informal discussions. Now that we are considering a reasonably sized initiative, we want to provide just enough information to get thru the second gateway in the process, Business Case Development.

Once a card moves to Ready for Business Case Development, a task or tasks can then be assigned to the submitter of the idea, the product manager impacted by the idea, or an appropriate stakeholder, to create the business case deliverables for this item.

Business Case Development
As with this entire process, keep the business case deliverable simple. You should be able to boil it down to reusable template of no more than 1 or 2 pages of PowerPoint slides and some appendices.

Items to consider in your business case are:

• Impacted business area of the organization
• Impacted business strategic area or theme
• A high level description of the suggestion (1 or 2 sentences)
• The financial investment rationale for the suggestion (1 or 2 sentences)
• ROI chart by investment, revenue, expenses (1 – 5 year)
• Scored Costs & Benefits (Fibonacci scored or simply High, Med, Low)
• Metrics used to gauge success or failure of suggestion
• Assumptions

You will likely have other items to add or remove based upon your own organization. The more you can standardize this information the better.

Here's how one organization structured program and project business cases into a single snapshot.

Figure 8 – Sample One-Page Business Case Template

Note that the Benefits & Costs sections of a business case are further elaborated in a separate more detailed document (not shown).

Once the business case deliverable is ready for review, the Product Manager, or appropriate stakeholder, can move the card into the Ready for Business Case Review column. A card in this column alerts Portfolio or Program Management that item should be prioritized and scheduled.

Just like the initial review, business case reviews should happen on a predictable schedule and be no more than 1 -2 hours. Once scheduled, the scheduler can move the item into the In-Business Case Review column.

The Business Case Review
The overall objective of the business case, is to demonstrate the organizational value returned by the initiative within a specified time frame.

The value identified, should be something you can quantitatively measured to determine success or failure of the initiative.

Your business case review should result in one of three paths:

1. Rejected - The idea’s investment/costs outweighs its value.
2. Business Case Refinement Needed – Further refinement of the business case is needed in order to make a decision.
3. Accepted - The idea seems feasible, in alignment with company strategy, its business value seems clear, but its complexity requires a deeper analysis for further assessment to validate this.

For rejected business case’s, the rejection reason should be documented on it's card and moved to the Rejected column.

If a business case needs additional refinement, perhaps there are some unanswered questions, these requests should be documented and the card moved back to the In-Business Case Development column and rescheduled once the information has been gathered and the card is ready for review again.

If the business-case is approved, it should move to the Ready for High-Level Analysis column of the Kanban board.  Note that it's possible that as a result of the business case review, it's determined the idea can be fast-tracked, and moved directly to the Ready for Project Prep column.

Leveraging a Kanban board to monitor the flow of the Portfolio & Program Management Ideation process, we've demonstrated how Kanban can be used by the Portfolio/Program Management team to provide a clear and transparent process, ensure appropriate governance of larger initiatives, and still encouraging agility by only requesting just the right amount of information at the right time.

It takes time for governance processes to evolve.  If you like the idea of a Kanban board to manage these processes, I recommend starting out by mapping your existing process activities first without consideration to Kanban, then once everyone agrees on the process, only then should you begin translating it to a Kanban board.

It's rather daunting to approach existing complex processes within any organization.  Part of agility is being able to evolve and improve. Be sure to incorporate periodic retrospectives to continually review your processes with your team and make incremental improvements along the way.

In the next and final article in this series on Agile Portfolio & Program Management - Ultimate Agility, we are going to discuss the final validation activity, High Level Analysis, and the the Project Preparation stage. We will also put everything together and demonstrate how to monitor and continually improve your overall organizational agility.

It would be great to hear about your experiences with addressing organizational governance, get your feedback on Portfolio & Program Management, and any suggestions you may have.

Agile Portfolio & Program Management – Part 1: Ideation

Executive Summary:
Being able to evaluate the influx of project ideas in large organizations can be a tedious and time-consuming process for management, and a confusing process for stakeholders. Using a simple Kanban board for the process of collecting and approving these suggestions, helps guide stakeholders through the process, provides approval visibility, and most importantly, prevents the loss of some really great ideas.

This article is the first of a three part series on Agile Portfolio & Program Management.

For quite some time now, both small and large organizations have been successfully executing agile and Kanban practices to manage individual projects at the team level, but one often overlooked area, is where agile and Kanban can be applied to portfolio and program management, especially at the point of ideation.

Simply stated, ideation is the process by which new ideas are captured, evaluated, and if approved, prepared for implementation. Ideation is the inflow of ideas and suggestions to both portfolio and program management. These ideas and suggestions may relate to the development of new programs, product enhancements, new products, improvements to a process, changes in infrastructure, or just about anything that a stakeholder might want to do that they think brings value to the organization.

Some Basic Terms:
Portfolio Management is the activities an organization performs to determine its overall strategic goals (e.g. Customer Care, Mobilize Workforce, Operational Efficiency) and the tactical programs made up of various initiatives to achieve those strategic goals. These types of strategic goals are referred to as Themes in Dean Leffingwell’s SAFe (Scaled Agile Framework) methodology.

Program Management is the process by which the organization prioritizes, manage dependencies, and oversees the implementation of initiatives within each program. These initiatives are performed at the team level.

Here’s a bird’s-eye view of the Portfolio & Program Management ideation process:

Portfolio & Program Management Ideation

Figure 1: Portfolio & Program Management Ideation - Bird's Eye View

Because new initiatives may impact a significant number of teams, customers, clients, and/or may require lots of resources, some level of governance is usually instituted to evaluate and validate these ideas to confirm their value (i.e. value returned over time vs. investment & expenses). If approved, these ideas are then formalized for implementation. Unfortunately, this evaluation and approval process can be very time consuming and complex, involving multiple sign-offs, reviews, documentation, and impact multiple teams and systems etc. This is where Kanban can come to the rescue!

Unfamiliar with Kanban? - Here is the basic Kanban pattern:
Within Kanban, although there are many ways to tweak a Kanban board, at its simplest, a Kanban board uses the following to represent the flow of work within a process.

Image Source: www.powerretail.com.au.

Figure 2: A Simple Kanban Board

Work is represented by a card containing a description of the item being worked on.
Work cards begin in the To-Do column, when work is selected from the To-Do column to be worked on it is assigned to someone and the card is moved into In-Process column. When work is complete, the card is then moved to the Done column. By looking at a Kanban board, you can see what work still needs to be addressed, what is currently being worked on, who is working on it, and what work is completed.

A Kanban Model for Ideation
You don’t need to be implementing the Scaled Agile Framework to use Kanban for ideation, but since the release of SAFe 4.0, the SAFe framework also encourages the use of Kanban for handling ideation.

Image Source: The Scaled Agile Framework

Figure 3 – Kanban Portfolio & Program Ideation in Safe 4.0 - Click Image to Zoom

The only issue with this recommendation, is that SAFe doesn't necessarily tell you how to implement this process, that's up to you.

Having worked with organizations attempting to tackle this problem, I’d like to outline a generic approach involving three validation gateways that can help your organization simplify this process, make it more transparent, and improve your overall evaluation and approval (aka cycle) times.

Here's a revised bird's-eye view of an ideation process with three validation gateways.

Figure 4: Portfolio & Program Management Ideation with 3 Validation Gateways

Gateways are activities performed by a Portfolio-Program Management team and/or a PMO to ensure organizational initiatives are aligned with the organization's strategic goals, feasible, provide timely value to the organization, and if so, are budgeted appropriately.

The next step is taking this process and representing it as a Kanban board to manage and monitor the ideation workflow and gateways until the idea is ready for implementation.

Your Kanban board can be a physical board on a wall, an electronic board using software like VersionOne , Atlassian’s Jira, or Leankit. You might even consider using both physical and electronic boards.

I like to use the term ‘Ready’ for work that is ready to be worked on (i.e. To-Do), once work begins, a card is moved to an ‘In-Process’ column, and when work is completed, that work is then moved into a ‘Done’ column. If the there is another activity in the process chain, the card can be moved into another ‘Ready’ column.

Here’s how the idea capture process might be represented.

Stage 1: Capture

Figure 5 – Kanban Columns for Idea Capture

First we capture the idea as a card in a queue or backlog (To-Do), we then may need to do some cleanup and preparation on the idea to prepare it for a formal review (In-Process), and finally after it is ready to be reviewed, we move it to the ‘Ready’ column awaiting to be reviewed in the Validation stage. You could consider this its own independent Kanban board, in which case the ‘Ready’ column would be considered ‘Done’, or if we expand the board to include the evaluation process, it would be considered as a ‘To-Do’ column.

Essentially, anyone in the organization should be allowed to submit an idea, but you may want to establish some of your own limits on this as well as a standard set of attributes and supporting documents you want to include on your ideation cards. Consider setting up a general mailbox account to receive ideas and have someone from the program or product management team actually enter each suggestion into a queue rather than allowing anyone to create cards directly.
The card attributes you choose should primarily be configured to handle different levels of analysis and evaluation.

As a guide, try to keep things simple and only require the submitter to include the information needed for each upcoming step rather than trying to capture everything at once. For more detailed information, incorporate the ability to associate supporting documents to card via links and/or file attachments.

Here are some example ideation card attributes. You will need to determine what works best for your ideation process:

Figure 6 – Sample Ideation Card

For continuous process improvement, you should be reviewing and refining your overall process, the board columns, and the card attributes on a periodic basis; think ‘agile retrospectives’.

Another important aspect, is to have a product owner to manage the Ideation Backlog/Queue. The product owner is responsible to groom the queue, ensure appropriate information is included for each card, merge duplicates, remove obsolete items, and prioritize which items should be reviewed next. The product owner will move cards they wish to work on into the In-Initial Evaluation Prep column. During this time, they may need to go back to the submitter for additional information or clarification. Once an idea has all of the appropriate information, the product owner will move the card into the Ready for Initial Evaluation column.
Now that you understand the basic Kanban board flow, let’s look at a process that involves three sets of activities.

Stage 2: Validate

Figure 7 – Kanban Columns for Validation - Click Image to Zoom.

Initial Evaluation
Once a card is in the Ready for Initial Evaluation column as a result of our idea capture process, the product owner or someone designated from Portfolio or Program Management can decide when to schedule this item for review. Note that the Ready for Initial Evaluation column is technically, the backlog (To-Do) for the Evaluation section of the Kanban board. Any card that shows up in this column is a signal to the owner of this queue to do something.

It’s recommend that you have specific periodic days each month or each quarter for this initial review. E.g. The third Tuesday of every month. The person, who scheduled the item, should pull those cards into the In-Initial-Evaluation column of the Kanban board, the week or month that that the review is expected to occur. This gives the reviewers a head-up on what items are coming up.

The first evaluation should be more of a discussion rather than a formal presentation, with the goal to determine if the idea has promise and is worth evaluating further.

Appropriate management, business stakeholders and tech leads should be invited to this session. The meeting should probably be no more than 1-2 hours, but this is entirely dependent on your process. Over time, you will get a sense as to how many cards can be scheduled for one evaluation session and you can set a work in process limit for the In-Initial-Evaluation column.

Your initial evaluation should result in one of three paths:

1. Rejected - The idea is not feasible, may not be appropriate for the business, or may already be addressed by an initiative in-flight.
2. Fast-tracked - The idea is clearly feasible, in alignment with company strategy, its business value is obvious, and is small enough that it could move directly to a team’s feature or story backlog.
3. Portfolio/Program Governance Required -The idea seems feasible, in alignment with company strategy, there is potential business value, but its complexity requires a deeper analysis for further assessment to validate this.

If you determine that the idea is not worth pursuing or is already being addressed the idea is rejected; the rejection reason should be documented on the card and moved directly to the Rejected column of the Kanban board.

If an idea’s value is obvious and small enough, it can be fast-tracked to project preparation, where requirements can be cleaned up, outstanding questions answered, and an implementation team assigned so that it can be added to that team’s feature or story backlog. Document the fast-track reason on the card, and move it to the Ready for Project Setup column.

Examples of fast-tracking might be application cosmetic and/or content changes, minor feature requests, and minor process changes. If it’s not obvious, consider sending it thru the full evaluation process, you can always re-route it back to project setup via fast-tracking.

One approach to determine fast-tracked items is to use the number of teams involved or impacted by the suggestion. If it requires two or less implementation teams, it can be fast-tracked and go directly to Ready for Project Setup, three or more teams may require the full portfolio/program management evaluation and analysis process.

When an idea requires further portfolio or program evaluation and analysis, the reason should be documented within the card, and the card moved to the Ready for Business Case Development column of the Kanban board.

A great feature of many online Kanban tools, is that they can also serve as a workflow application.

Cards can have tasks associated to them within each activity and tasks can be assigned to people. Once a card moves to Business Case Development for example, a task can then be assigned to the submitter of the idea, the product manager impacted by the idea, or an appropriate stakeholder, to create the business case deliverables for this item.

Identifying which tasks are performed during each activity ensures the process is followed, all appropriate information is gathered when needed, provides real-time status, and an audit trail. You may still consider maintaining a simplified physical board somewhere so that anyone can see it a glance what is going on during the ideation process.

By this point, you should have a basic understanding what ideation is, how Kanban can be used for Portfolio and Program Management ideation to, serve as a process guide for stakeholders, how Kanban tools like VersionOne and Atlassian’s Jira can be used for workflow management, how Kanban boards provide visibility into the current state of work, and finally how to use Kanban to prevent the loss of valuable ideas.

In Part II of this three part series on Agile Portfolio & Program Management, we'll discuss the next step in the validation process,  learn how to create a 1-page business case, and how to incorporate organizational oversight into the process while still encouraging organizational agility.

I’d love to get your feedback, hear about your ideation experiences, or or anything agile.
In the meantime, keep those ideas coming!

The 3 most important questions to ask your product stakeholders.

Asking your stakeholders the right questions early on in product development is critical to focusing discussions, encouraging product innovation, and ensuring product success. 

With the new year here, I thought it would be a good time to discuss ways to get projects off to a good start.

When initiating any project, it's good practice to get an understanding of your stakeholders challenges and project expectations.  Asking your stakeholders the right questions early on in product development is critical to focusing these discussions, encouraging product innovation, and ensuring product success. 

Product managers and analysts often start out by identifying a product's current state and eliciting high-level requirements from the product's stakeholders. Stakeholders include product owners, subject matter experts (SMEs), customers, clients, product users, partners, etc.

Some of the more common questions I hear asked are:

• What is the problem with your existing process/system?
• What do you want it to do?
• When do you need it by?
• What is your budget?

While these are all completely appropriate and necessary questions that should be asked, using these alone to drive your solution can often limit the potential value delivered to your stakeholders and can waste time and resources delivering something different from what the stakeholders expected.

Of course you want to understand the existing system and processes, but by focusing too much on an existing system's problems, you often end up with a myopic view of the stakeholder's real goals and the product itself when developing your product vision.

For projects which are designed to replace a legacy product, teams tend to assume that the objective of the project is to build the new system on time and within budget.  The result being epic, features, and user stories written to mimic the legacy system but with newer technology and platforms and perhaps a few new features.

But just getting a system built on time and within budget should not be considered the real objective. While this is definitely important, the real objective should be to accomplish something beyond the product itself.

 This leads to the first question:

1.       What are you trying to accomplish?

Because creating or amending any kind of product requires significant collaboration between development teams and stakeholders, it's critical for everyone involved to understand the context for those interactions. This requires some basic questions that need be asked at the onset.

I'm guessing a lot of those reading this have experienced this situation: Your friends and acquaintances find out you work with computers, and now is their opportunity to ask you all of those tech questions they've been meaning to resolve (this usually happens at a party).  I often get questions like, “I just upgraded my OS and can’t seem to do X in this application anymore, how do i fix it?” My initial instinct is to start out by trying to help them resolve their specific problem, but eventually, I almost always end up asking, what is it, that you are you trying to accomplish exactly? You will be surprised by the answers you get from this question.  It’s more common than not, that I find someone trying to accomplish a task either with the wrong tool for the job, an inefficient process, or both. Many times, the simplest solution is using an entirely different application, using the application a completely different way, or using some kind of external service to perform the activity.

Granted there may be some costs for involving new software, hardware, and services, which sometimes results in shock and horror that I'm even suggesting they pay for something; even if it is going to save them hours of time in the future. 

By asking your stakeholders what they are trying to accomplish first, before diving into their problems, allows you to understand your stakeholder’s goals from a business standpoint rather than from a systems standpoint, and tends to keep the conversation strategic rather than tactical.

Examples of strategic goals might be:

• We want our clients to be healthier utilizing our services.
• We want our users to find music all day that makes them happy.
• We want to create furniture for our customers that makes them feel organized and peaceful.

Get the idea?

When an entire team understands the business's strategic goals, it helps align team members during release and sprint planning processes by making it much easier to determine what features you need to focus on first, helps focus story prioritization, and also opens the team up to thinking about new and innovative ways of accomplishing these goals many times leading to disruptive solutions.

2.       Why do you want to accomplish it?

The next question to ask is, why do you want to accomplish this goal or objective?

Asking this question often reveals entirely different understandings of the product amongst stakeholders, leads to better stakeholder alignment, and gives everyone a more holistic view of the product. 

This question also helps guide your solution and architecture choices because it tends to bring out  non-functionalrequirements (NFRs) such as regulatory, system availability, volume, and performance requirements. E.g. the decision to install something locally or in the cloud.

The answers to ‘Why’ also provides support to your user stories.  In the generally accepted format of ‘As a user, I want to <do this thing> so that <I get this benefit>”. Tt’s the ‘So that’ that tends to take on a more meaningful purpose and understanding by your team, and can open up more creative and effective ways of accomplishing a task no one may have thought of before.

For example, a stakeholder may want to sort a report a specific way so that users can reconcile inventory easier.  A better understanding of the goal, may trigger a team member to suggest using a more automated approach with a scanner and/or mobile device instead of printing out a better sorted report.

3.       How do you measure success?

Finally, once the What, Why, and How are identified, you want to be able to measure the results of your new product features, and/or processes, to determine if they are accomplishing what you set out to accomplish.

In my example of helping my friends with their tech problems, I mentioned how some of them balked when asked to pony up some additional cash for a better solution.  When assessing costs, the more clearly we can demonstrate the savings your stakeholders will receive, the more justification you will have (or not have) for the cost of the solution. 

While it’s important to deliver features on time and within budget, this should not be the only method to judge the success of your project (unless of course your project was to introduce a better way to deliver on time).  You’re going to need other ways to quantitatively measure your success.  This may be measured through a variety of things such as throughput (how many customers can be serviced per day, how many widgets created, etc.), time (time to deliver, wait time, response time etc.), dollars (revenue, expenses, profit, etc), customer satisfaction (negative/positive survey comments, Net Promoter Scores) etc.  You and your stakeholder need to agree on these measurements and they are items you should be able to track throughout the project. I suggest keeping your success measurements to just a handful.

Once you have identified your success measures, you should be able to clearly demonstrate feature successes and failures to your stakeholders and to the entire team. Having this information makes it easier to communicate status and should lead to better retrospective conversations of what went right, what went wrong, and what can be done to improve things.

With your team and stakeholders understanding the strategic goals, the purpose of the goals, and how to measure your success, it should make for smoother and more innovative sailing on your new project.

Here's to new beginnings! Happy New Year.

Agile Release Planning - Aligning with Executive Management

Executive Summary:

For longer-term technology projects, a quarterly planning Kanban board will not only help with release planning, but is also a great way to align program management with executive management on releases, resource capacity planning, costing, and ongoing project status reporting.

Quarterly Planning Kanban Board. 

In a previous article, I discussed methods to break down your product epics and features that were understandable to both executive management and product stakeholders, along with how to use the SAFe weighted shortest job first (WSJF) method to prioritize these features. In this article, I'd like to discuss a clear and simple way to present your agile release plans to executive management.

As part of agile release planning, you will need to identify epics and features that will be implemented over longer periods of time.  It's said that a picture is worth a thousand words, but with the advent of many new agile tools,  too many pictures can sometimes be overwhelming and information can get buried, especially when trying to communicate plans to executive management. This often results in miscommunications and many long unnecessary status meetings. As a program and/or product manager, it's critical you find a communication approach for both you, your teams, and more importantly, you executive management, that clearly, and accurately, depicts your initiative's plan and status.

Let’s look at the previous initiative example I presented for integrating a cloud-based HR system into your existing environment to replace a legacy HR system.

A simplified set of phases of the project identified were as follows:

Integrate new cloud-based HR System

·                  Environment Setup

·                  Integrate vended application with existing legacy systems

·                  Migrate existing employee & contractor data into vended application

These phases are what I would call super-epics.

After further analysis we came up with the following sub-epics and features for the Integrate phase:

Here is an example of expanding the Employee Update epics within the Integrate phase into features.

(Super) Epic	Sub Epic	Feature	Team A	Team B	Team C	Vendor A
. . .
HR Cloud Integration	Employee Update	HR Cloud Core Data Update		X		X
HR Cloud Integration	Employee Update	Facilities Location Update	X	X		X
HR Cloud Integration	Employee Update	Telecom Update			X	X
. . .

Example Epic and Feature Analysis by Team.

Note that we are expressing our epics and features from a business standpoint and not from a technical standpoint. We know which systems are impacted by identifying which teams need to be involved to execute specific features.  So Team A might represent the Facilities system, Team B might represent the new HR system, Team C might represent the Telecom system, and Vendor A might represent the HR System's vendor.

If these were architectural epics, of course we would reference specific tools, systems etc., because from an enterprise architecture standpoint, these systems, tools, and middleware are their business. Make sense?

• From executive management’s standpoint, they are primarily interested in when the main project phases (super-epics) will be completed and how much it’s going to cost them.

• From a program manager’s standpoint, they are primarily interested in when the epics (super-epics and sub-epics) will be completed and are they on or over budget. 

Note that you can call these levels whatever you want, but the point is that what management likes to see is generally at a much higher level than what execution/implementation teams like to see, and that you just need to be conscious of this. Some tools like Jira Portfolio can help you align these differences.

Here's another way to think about it.

Keeping in-line with Dean Leffingwell’s scaled agile framework (SAFe) concepts of implementing interconnected Kanban and SCRUM boards to manage a company’s portfolio initiatives, programs, and associated projects, we get this hierarchy of epics, features and user stories where epics represent executive strategy, features represent program management, and stories represent the tactical execution of programs.

Image Source: adapted from http://versionone.com Enterprise Agile presentation. 

 To help align both program/product management and executive management for longer-term planning, and to ease management into concepts of lean and agile such as Kanban boards, epics, and features, I recommend starting off with a Kanban board based on quarters. 

Here’s the basic approach.

At its simplest, each column on the Kanban board represents one quarter and an epic is placed in the quarter that it is scheduled to be completed.  Within each epic you can include the features that are planned to be released within that epic. It’s up to you to define your definition of done for each item on the board, and everyone should be very clear about what this means. i.e. is it just user acceptance tested, or does it mean it’s been rolled out to the field.

You can include as many quarters as you want, but I’d recommend making no more than 6 – 8 quarters at a time. You can reuse previous quarters on the board about every 6 – 9 months.  This view shows only the current year, but you can include quarters from the previous year and next year as well.

Quarterly Planning Kanban Board. 

I encourage program management to maintain this as a physical board in a place where executive management will see it as well as the entire team.  For remote teams, you can also maintain this in tools like Jira and VersionOne, but just be sure that you incorporate a process to ensure this has constant visibility.

Note that an epic may appear in multiple quarters because features within an epic will likely be incorporated into different releases. You can further refine this board by using color post-its or indicators on the post-it, to indicate whether something is on-schedule, delayed, or has a major blocker, and/or you might consider adding traditional "To-Do", "In-Process", and "Done" Kanban columns within each quarter.

Additionally, horizontal columns can be used to indicate which team is primarily responsible for which feature. You might even indicate specific release trains on the timeline as well.

Quarterly Planning Kanban Board with Team Columns. 

And yes, it's not that much different than a traditional calendar, but it's familiarity and bridge into agile concepts is it's key benefit, not to mention it can easily be incorporated as a Kanban board in just about any agile tool.

Another valuable dimension that can be represented here are the points and/or hours for each feature as well as the total points or hours for the quarter and for each team over a period of time. This allows you to plan and identify team commitments, constraints, and availability, along with a rough idea of both team and quarterly estimated costs. After a quarter has completed, you might even show planned versus actual hours to help with the next period of planning.

Quarterly Planning Kanban Board with team and quarterly hourly totals.

Deciding what to include and how to manage the quarterly Kanban board is something that will evolve over time and will be determined by your project and organizational needs.

If you focus on information that maximizes the value provided to your management teams and minimizes the effort to manage the board itself and you will find that implementing a big visible quarterly Kanban board will help bridge the gap between executive management and program management and help reduce unnecessary project status meetings saving everyone's time.

I would greatly welcome your feedback and experiences regarding agile release planning and management.

Blog header Image Source: theflowcentre.com