Concept to Cash cycle (C3) in #Agile

  1. Idea
    Everything stats with an idea!  It could be an idea for a new product/service offering, or it could be a new market opportunity that you want to pursue, or it could be that you want to fix all the ‘holes’ in your existing product in order to gain better market share. Bottom line is that it all starts with a seed that we call Idea!
  2. Visioning
    Remember, you are not alone working on this idea! You will have teams working on this idea to drive it towards (becoming) a reality. You should be able to convey your vision about the product/service. We use this special format to describe your vision.
  3. Story mapping / brainstorming
    Now, armed with your Vision statement, you can start pulling all the right parties, the stake holders into conversation. You can lead a brainstorming session to uncover, unearth the work that needs to be completed in order to make this vision a reality. Don’t overwhelm yourself with lot of details. Key here is to stay at 50K ft and capture high level (slices of) work that would need to be completed (don’t worry about how, when, who does it. For now, the focus is on WHAT.
  4. Roadmap
    Now that we know what work needs to be completed (based on the Story mapping exercise), we can start putting them together on a roadmap that will help us make the product a reality. At this point, we want to focus on next 6 to 12 months, and create a product road map; what features would be built, and when we would like to release them to the market. As we do this, stay focused on creating value with each product increment that we push to market.
  5. Release Plan
    With the roadmap in place, we can start pulling in all the teams that would be working on them. Complete some dependency analysis, identify all the teams, and get them into release planning session. Here, we are focusing on next two to three months, and what product increment we can work on and get it out to market. All the teams can discuss these features and functionalities, what it will take (effort) for them to make it a reality, what are the dependencies, and how they may impact the “Push to Production” effort. At the end of this session, these teams come out with an intended plan of HOW they will build this product increment.
  6. Sprints / Iterations
    Based on the intended plan that came out of the release planning session, teams go into individual sprints, get into more details as to what tasks needs to be completed. Here, we focus on next two to three weeks at a time.
The key to success here is not to get hung up on getting the product to be ‘perfect’ before you go to market. WE focus on creating a version, an increment of the (ideal) product and push it to market; identify the minimum viable product (MVP) with which we can go to market. And, then repeat this cycle on a smaller feature sets, smaller increment of the product (that builds on the increment that we released to market earlier).
How long is your Concept2Cash cycle? How long does it take for your organization to take an idea to market?
Would you want to shorten this, want to increase your Idea2Market speed?
#Agile can help, I can help! Get in touch with me and we can shorten this cycle for your organization.
Read More

#Scrum flower

Please accept this beautiful flower to start your day; I like to call it #Scrum flower. Look under the ‘pretty packaging’ and you will find these ingredients:
  • Team as we know is in the center of Scrum. It is all about team!
  • This centerpiece is surrounded by the five values of scrum: Focus, Openness, Respect, Courage, and Commitment
  • And, all these is supported (the stem, and the leaves being) the three pillars of Scrum: Inspection, Adaptation, and Transparency

As I said, please accept this beautiful flower to start your day, and be generous to pass it on!

Read More

#agileReleasePlanning wall

Each column represents a Sprint in the release cycle. Each row represents a team that will be participating in this release planning exercise.
Agile Release Planning Wall

 

Based on the history, make up of the teams, and what is needed in the functionality, the Chief Product Owner (CPO) may decided to pre-assign some of the work slices (open for discussion and negotiations with the team later on).

Read More

Motto of #Agile team

Motto of #Agile team – Sink or Swim together as one unit

Read More

Are you a TEAM?

 

Read More

Agile Data Warehouse series: What it is? – the workflow

In my previous post , I announced my intention on writing a series of posts talking about my recent experience with data warehouse build out in agile transformation of EDS for a Fortune 100 company. Let’s continue our discussion on this interesting topic. 

So, what exactly it is? What do I mean by agile data warehouse build out? 
 
First of all, let’s talk about Data Warehouse in general. A data warehouse initiative typically involves building out data structures in the enterprise data model, pulling data from multiple sources, doing some (data) transformation, and then ‘parking’ them into the target data structure. Sounds about right? 
 
At a high level, at least, this is the work flow for a data warehouse build out. To get to next level of details, your data warehouse build out includes:
  • Identifying the data elements and sources for that data
  • Coming up with logical data model that will support the business’s analytical needs
  • Often, getting this logical model; or as technical teams would say LDM (Logical data model) approved through some governance body in the organization
  • Getting the physical data structures, PDM (Physical data model) created
  • Extracting and transforming data from various sources to load into the physical data structures
To summarize, a typical data warehouse build out contains of following work flow (of events):

Typical workflow for a Data Warehouse build out
Typical workflow for a Data Warehouse build out
[Please note that we will be modifying this as we discuss the topic further]
Now, let’s talk about Agile data warehouse (ADW).  By ADW, I mean:
  • We build the data warehouse in increments
  • Delivering Potential shippable increment (PSI) of the data warehouse at a regular frequency [and not have customers waiting to get the data warehouse as one big-bang delivery]
  • Involving customers through the build process 
  • Understanding customers, and their needs – what are the business reasons for them to request this data warehouse
  • Focus on creating customer value incrementally, and not the technologies or the implementation of it. Shift your focus from technology (and data elements, data structures, primary key, foreign key, etc.) to customers needs. 

Often times data folks are so focused on their tables and primary keys that they start driving the build out from that vantage point only 🙁

Let the customers’ need be your guiding beacon! 
 
[Next post: Know thy customer!]
 
Read More

Agile Data Warehouse series: Intro

I have been involved in agile transformation at a Fortune 100 company, specifically in their EDS division. EDS being a central steward of all the data warehouse the company uses, it has been a challenge to rollout agile in this centralized group. In a series of articles, I will talk about my experience of agile rollout in EDS and data warehouse build out, the challenges we faced, and the ‘model’ that could be used. My hope is this series of articles will help you get a ‘head start’ when you have to work in such a situation.

This series of artless will include:

  • What it is – what do I mean by agile data warehouse?
  • Challenges agile teams face in an enterprise
  • Patterns for writing User Stories: Different ways of Slicing the work
  • Agile model that helps us develop and deliver data warehouse incrementally, delivering value earlier, and driving RoI for our customers; internal and external.

There is no organization that can live (and prosper) without data warehouse. Every organization is using data warehouse (on a smaller scale, perhaps) to house relevant data and use it to their advantages.

Look forward to ‘seeing’ you all here in this series.

[Next post: What it is? – the agile data warehouse]

Read More

UML, Lightweight requirements gathering, and User Stories

As described by Mike Cohn, a User Story has several components to it; and the Description should be written in following format.

As you can see, this format basically focuses on three parts: role, action, and value creation. You would be looking to collect the requirements while starting on a new project. And, you have an unlikely ally, a partner in the form of UML – the Unified Modelling Language that can help you with this. UML can help you in your quest for collecting meaningful user stories.

Anytime you start discussion of any application, you will start with Context diagram for the proposed solution. Context diagram, in essence is a diagram showing your proposed solution and all the players that will interact with this solution. I have found this (context diagram) to be extremely useful in getting the requirements gathering going.

Let’s look at an example. In my book, Agile Release Planning, I talk about an example project of creating a website www.nflFans.com to act as web portal where all football fans can buy and sell game tickets. As part of the lightweight requirements gathering, I would have my team start with the central idea; putting a box in the center to show the future proposed solution.

Now, start discussing the interactions and all the actors that would be interacting with this proposed application. There are several roles and actors, human as well as non-human, that will interact with app. Actors such as Football fans, our web portal as a system, credit card companies for credit card processing, Football teams for providing seat availability, etc. As you discuss various interactions, continue capturing the actors into this context diagram. Now, the context diagram looks like this.

If you overlay User story format on top of this diagram, you will realize that this context diagram give you the first part of your user story As a/an.

UML helps you keep the discussion at a high level, rather at the right level. In the next episode we will talk about extending this context diagram to get second part of the user story using this lightweight requirements gathering approach.

Read More

Lucky 13



Do you remember the feeling you got when your five year old scored his/her first goal? Makes your chest grow bigger with all the pride and joy? Isn’t it?!
I got the same feeling today (13Jun2012) evening when 500 people were clapping their hands at the end of a presentation. 
The presentation was about an iPhone/iPad app called DEHS, the venue was the board meeting of Downingtown School District Board meeting, the app was DEHS App for the school, and  the developer and presenter is my son:-) 
I know, I know, I am getting away from my usual subject of writing about agile world. But, this evening I can not resist but enjoy this pride and joy, and write about it. 

I was pleasantly surprised about:
  • his focus and confidence
  • his quick thinking on his feet (we, myself, him, and his school principal did not think that there will be so much turn out)
  • his calm, collected speech in front of 500 people (check out the video here)
  • how relaxed he was even when unexpectedly he was in front of so many people 


“Dhawal, Great job! You did fantastic job! 
Lot of kids come to me with suggestion, start on something, and never finish it. On the contrary, you started this app development and stuck with it. Even when I could not give you enough time and directions (due to other commitments at school) you continued to plow through it. It shows your dedication and sincerity. Good job!”
Said his principal at the end of the presentation (these are not exact words, but my best attempt to recollect what he said)

Dhawal, you made my day! I am so proud of you 🙂

P.S
Download his DEHS (and his other apps) here, follow him on twitter @AreteSolutions, send him email with words of encouragement, and promote him. 
Thank you Principal Hurly for all your encouragement and support!
Read More

Productivity Index


We all are familiar with these dials! This is a picture of my car-dashboard, giving me reading on various aspects of my car and my driving (habits). Do you have a dashboard that you use to navigate your Agile projects through the real life challenges? If you do have it, what are the dials you use on it?

If you don’t have the dashboard for your project, at a minimum, I would strongly suggest of posting this dial (shown below) to show the productivity of your team.



Essentially, it is tracking what Value you are creating (BV) against all the Effort (SP) you are putting into it. As mentioned on Wiki, Productivity is a measure of the efficiency of production. Productivity is a ratio of production output to what is required to produce it (inputs).1
You can consider it your team’s Productivity Index (PI).

I like to chart it on a scale of Zero (0) to Two (2). If your team stays on the left of the dial, your team needs to work on improving the velocity and productivity. On the other hand, if your team stays on the right side of the dial, your team is producing more than what it is taking in. If you are staying somewhere in the middle of the dial, your team is breaking even.

Here are PI dial for three different teams:

Team “Silver”
Team “Gold”
Team “Platinum”


Which team would you rather have? Which team would be proud of coaching?

Notes:
BV=Business Value
SP=Story Points
PI=Productivity Index

Read More

the Ten commandments of User Stories

An interesting thought came to mind when I was explaining User Stories to one of the team I am coaching. There are some guiding principles and practices that we must follow to be successful in writing and executing the User Stories. These are what I call commandments of writing a USer Story.

What do we mean by Commandments? Let’s first look at the definition of “Commandment”.
The commandments could be a religious or moral imperatives; they act as “guiding lighthouse” to a purpose, and you hope to live by those commandments to reach certain purpose in life. In essence, they are guiding principles for individuals you hope to live by.

Similarly, in Agile projects, the purpose is to deliver business value; in small increments with each iteration. User Story is the neucleus of Agile project and success of the project heavilty depends on them. I belive there are “Ten Commandments of User Stories” that will help any team venturing on the Agile journey and guide them to success.

So, here they are: the Ten commandments of User Stories

  1. Thou must deliver Business value
  2. Thou must prioritize User Stories based on Business Value (by Product Owner) and Team must take collective ownership
  3. Thou must be validation centric
  4. Thou must be “Done Done Done”
  5. Thou must have 3Cs
  6. Thou must be Crosss functional (california roll)
  7. Thous must INVEST in User Stories (the six attributes)
  8. Thou must Size and Estimate (using Story points)
  9. Thou must Swarm (and complete few stories at a time)
  10. Thou must post Story Burnup chart

Read More

Feature burn up / completion chart

MMFs: the Minimum, Marketable, Features


As I describe in my book, Agile Release Planning, an MMF is a group of minimum functionality that we can release to customers. By ‘marketable’ we mean that the functionality can be released to customers for their use, and thus the word ‘marketable’! So, by definition, MMFs must bring significant value to customers.

As MMFs are of most value to customer, it makes sense to track the progress we make on them. Feature Burnup chart or Feature completion chart is an invaluable tool in your toolkit. It is simple yet very effective chart that you can use to convey progress (or lack of progress) that you are making on various work slices that are of interest to business.

Here is an example for the sample project that I mention in my book:

In this chart we are plotting MMFs on x-axis; in the order of priority, with highest priority item on the left, and lowest priority item on the right. As you can see, it conveys the progress we have made so far on each MMF as well as what MMFs are complete vs. what MMFs are being worked on actively by the team.


If you see progress on right (lower priority MMFs), you should question why team is working on them. This might be legitimate, but you at least want to ask and get confirmation for a valid reason to work on lower priority items.

Another variation of this chart is to use percentage complete as shown in example below.



The previous chart (using SPs) gives you relative complexity that you can use to compare the effort involved among MMFs.

As I said, this chart is simple yet very effective. And, I am making it even more simple for you to create it. You can download a template and create this chart in just few clicks.

Business scenarios where I would use this chart:

  • My director is asking for status on different slices of workin my project
  • Why I see activity on the lowest priority MMFs
  • What progress we are making, and on what pieces of the project

I have infact asked my directors to always have this chart handy. I recommend that all product owners carry this as well.

You should update it at end of every sprint. You want to share this with your stakeholders at the sprint review. And, also attach impediment list to this chart, especially when you are not making progress on some MMFs.

Read More

Light weight Documentation..

I used this software tool to complete documentation at one of the Client site I recently worked at. Rather than create long, boring MS Word documents, we created short Videos ‘showing’ how to complete certain tasks/activities. The software is available free of charge here.

The only catch with the free edition is that you can not create a video longer than 5 minutes. This limitation, though, works to your advantage as anything more than 5 minutes would get boring. This forces you to keep the video short, forcing you to pack more ‘punch’ within this 5 minutes.

This, obviously, does not replace the Word documents, but rather is an extension of Word documents and makes them ‘light weight’. And, this tool makes the documentation process more fun!

Now onwards, enjoy the (dreaded) documentation!

Read More

Reading List..

I have been involved in transitioning two of the largest organizations (in the North America) to value driven project methodologies such as Agile, Scrum, and Lean. During these transitions, I have coached several teams, managers, and executives on Agile Practices and principles, and have often been asked for recommended reading list. I have accumulated a list of references that I often recommend my new teams read when starting their journey on Agile. Here is the list for your reference.

Books

  • Agile Project Management with Scrum (Schwaber)
  • User Stories Applied (Cohn)
  • Scrum and XP from the Trenches.pdf (Kniberg)
  • Scaling Software Agility (Leffingwell)
  • Agile Estimating and Planning (Cohn)
  • Implementing Lean Software Development: From Concept to Cash (Poppendieck)
  • Test Driven Development: By Example (Beck)
  • Agile Software Development with SCRUM (Schwaber)

    Online References

  • Scrum Alliance
  • Being Agile is our favourite thing
  • Agile Manifesto
  • Agile Wikipedia
  • Mountain Goat Software
  • Jeff Sutherland NYC Spin
  • Scrum and XP from the Trenches
  • Agile Project Leadership
  • Agile Management
  • Ward Cunningham on the origin of the term Technical Debt
  • Agile Thoughts
  • Testers Shine on Agile Projects
  • Requirements Up Front
  • Agile Requirements
  • BSA Role
  • It’s Not Just Standing Up
  • Big Macs vs. The Naked Chef
  • Agile Has Crossed the Chasm
  • Constructive Disruption and Compromised Agility
  • Kanban in a nutshell

    Learn from the experts: Blogs, RSS Feeds

  • Schwaber on Scrum
  • Agile Advice
  • Agile Alliance
  • Agile Management Blog
  • Implementing Scrum
  • Pages tagged with ‘agile’ on del.icio.us
  • Stevey’s Blog Rants: Good Agile, Bad Agile
  • agile at google
  • The Planning Onion: Five Levels of Agile Planning

    Shameless post: link to my blog

  • Unlearn what you have learnt
  • Delivering the W, One Game at a Time
  • Field of View
  • a quick introduction: What is Scrum?

  • Read More

    Field of View..

    As we all know, in Agile, planning is a continuous process. We do not believe in big planning upfront; rather planning is a continuous process and we do planning at different layers, at different stages in the life of a project. Mike Cohn refers to these multi-layer planning as Planning Onion.


    At different layers of this Planning Onion, the project team focuses on varying level of details at different stages of project.

    At the inner most layer, the daily planning, team focuses on the particular day (What am I planning to do today? Are there any impediments?). So, at the inner most layer, we can say that our field of view is just that particular day, we focus on one day and thats about it.

    The next layer is Sprint planning, often refered to as Iteration planning. The team is now expanding the full of view and now focusing on one iteration. Team’s field of view is expanding from one day to couple of weeks (depending upon the length of the iteration.)

    So as we move from the inner most layer to outer layers, the field of view is expanding. As you get to the inner layer the details become more and more clear.
    If I put a flashlight in front of this planning onion, you will see that the light is brightest near the flash light at the inner most layers, and as we go the outer most layer the light becomes more and more dim, the details become hazy. So, with this flash light, you would still be able to see (kind of) the road map if you were looking far ahead but at the same time it would not give you lot of details.

    Read More

    Star Wars and Agile..

    In the Star Wars movie The Empire Strikes Back, Luke tries unsuccessfully to rescue his X-wing fighter from the swamp. After some time, he gives up. He tells Jedi Master Yoda that lifting the fighter is impossible with the force, the new approach Yoda is trying to teach him. Yoda has these words of wisdom for him:
    “You must unlearn what you have learned.”

    Scrum is no different! Like the Jedi force, the Scrum framework is conceptually easy; it’s putting Scrum into practice that is difficult. In order for a team to be successful, the team members must unlearn what they have learned so far in their careers.

    Check out my recent article for more details on what habits must be broken to succeed in Agile Adoption.

    Read More

    What is Scrum?

    Recently, a friend of mine asked me “What is Scrum?

    I started thinking what is the best (and quickest) path to introduce a person to Scrum? So, I started my research for references; and here is a list of online resources that I feel can be used to get a quick familiarity with Scrum.

    Enjoy!

    Here are some more online resources:

    Read More

    Harvard Business Publishing and Agile..

    I recently read an article from Harvard Business Publishing on “Why Good Projects Fail“. As we all know, the failure rate for projects is very high; more than half of the projects fail! This is especially troublesome in Traditional Project Management as you would not know if the project is failing until it is too late (remember, one big bang delivery!)

    In this Harvard Business Publishing, the author suggests using rapid-results initiatives in order to minimize and mitigate the risks of failure. What he means by that is “to use small projects designed to quickly delivery mini-versions of the big project’s end results”. Do you ‘smell’ Sprints here!?

    He goes on to list several defining characteristics of this rapid-results initiatives approach such as:

    * Results oriented (As we know, with each sprint, our goal is to deliver value to the Product Owner.)
    * Vertical (Refers to Cross functional team)
    * Fast (Refers to Sprints and Releases)

    There are many parallels in this article and what we do in Agile landscape. Check out the article here to find out more details.

    Read More

    Product Backlog, Product Owner, and Business Value (BV)

    As we all know very well, the Product Backlog (PB) is very critical artifact in Scrum and Agile. PB should be the central repository of all the work that needs to be completed in a Project. We capture all the work (as we know as of Today) in the form of Epics, Features, and Stories. The Product Owner (PO) would then be responsible for providing the priorities on them. The PO may also decide to use the Business Value (BV) to help him/her prioritize the Product Backlog.

    While there is no explicit formula for Business Value, the Product Owner should be making implicit decisions based on his/her experiences. While assigning BV to Features and Epics, the Product Owner may consider some of the following criteria:

    * What the team has accomplished so far?
    * What the team can complete within the Release Cycle?
    * Complexities
    * Dependencies
    * Impediments
    * Market Size
    * Market Timing
    * Opportunity Cost

    If you ‘zoom’ into these criteria and look at them closely, you will realize the first few criteria drive the Priority and Sequencing of the Feature and Epics. The last three, Market Size, Market Timing, and Opportunity Cost, are the ones that will drive the Business Value.

    Read More

    Google CEO on pair programming..

    Recently, I read an article on Business Week. In this article Google CEO Eric Schmidt describes the simple principles that helps the company drive innovation.

    In this interview, he mentions that the best programming team is a “telephone call,” which is two people, you and I, programming together. Sounds familiar! He is describing the pair programming.

    He goes on to mention that the second-best programming team is, everybody fits into a single room. All other variants are bad. Do I hear co-location here?

    There you have it! Even Google CEO is promoting pair programming and co-location.

    Read More