- 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! - 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. - 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. - 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. - 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. - 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.
-
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!
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- 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
Typical workflow for a Data Warehouse build out [Please note that we will be modifying this as we discuss the topic further] |
- 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 🙁
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 MoreAs 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- 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!
Dhawal, you made my day! I am so proud of you 🙂
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.
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
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
- Thou must deliver Business value
- Thou must prioritize User Stories based on Business Value (by Product Owner) and Team must take collective ownership
- Thou must be validation centric
- Thou must be “Done Done Done”
- Thou must have 3Cs
- Thou must be Crosss functional (california roll)
- Thous must INVEST in User Stories (the six attributes)
- Thou must Size and Estimate (using Story points)
- Thou must Swarm (and complete few stories at a time)
- Thou must post Story Burnup chart
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:
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.
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 MoreI 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
Online References
Learn from the experts: Blogs, RSS Feeds
Shameless post: link to my blog
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.
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.
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 MoreRecently, 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:
- The Agile Elevator Speech
- Scrum in Five Minutes
- An Introduction to Scrum
- Scrum et al. – Ken Schwaber (who created Scrum) on Scrum at Google
- And, of course, if you are (American) football fan, you can read my article that draws similarity between The Partiots – a Football team and some of the Scrum practices.
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 MoreAs 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 MoreRecently, 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