Archive
Lean Startup (LS) method for product management
Startups should not implement the practices common in existing companies because they are not not smaller version of large companies. The LS movement is aimed to establish appropriate practices for startups which are different from what MBA graduates learn in business schools. Thanks to Steve Blank who has articulated the philosophies and principles in his web, videos, books and others. Read more…
Leadership in Scrum through evolving goal definition
User stories creation is a useful mechanism for expressing product features collaboratively. However, having sprint goal as list of user stories, based on team velocity, from my view reduces the business value of the sprint. Read more…
Set-up which Kanban serves us more
The setup is a project involving sub-contractors from different vendors working in highly regulated industry.
The objective is how to make these diverse skills work as self-organized team?
The challenges are:
- Strong command and control culture.
- Non streamlined views on how work needs to be done.
- People work independently with fear to become inter-dependent.
Time-boxed Value Stream
For large organizations, projects are often characterized of being:
- Involve people from various departments with separate reporting structure.
- Involve contractors from multiple vendors.
- Introduce technology which is unfamiliar to the employees.
- General disagreement or even lack of appreciation of the project approach.
- Multiple chiefs and puzzled doers.
- Software development is sub-component of the project. Read more…
Risk management for ScrumBut
Once I read that a project plan without risk assessment is a kid’s plan. Scrum is great framework design around “continuous risk mitigation” or probably avoidance.
Organizations who run projects in “command-and-control” mentality and making transition to Scrum are challenged and normally resort to ScrumBut implementation. ScrumBut is a low-fidelity flavor of Scrum which for me can be worst than command-and-control as it deprives the organization from doing full-fledged risk management.
Risk management is a proactive critical component in either Agile or traditional world. Agile project management de-emphasizes formal risk management. Because if Agile is adequately implemented then all benefits of doing risk management are attained. From my view, good Agile implementation can provide results which far exceed the implementation of formal risk management.
ScrumBut is where the organization wants to move to Agile but held back by its legacy of bureaucracy and inefficiencies. ScrumBut is where leadership is in the test and instead we have mediocre people who try to survive by implanting waste. That waste creates environment where morale is low and is characterized by excessive motion but with little accomplishment.
For ScrumBut I highly recommend going back to the basis of pro-active project management which can be implemented through effective risk management at various levels including:
- strategic
- technical
- teams
- sub-contractors, and
- others
Ignoring formal risk management in ScrumBut creates domino effect of spiral project failures, because of losing the pro-activity which is the back-bone of Scrum.
Transition of a business analyst to product-owner
I had a meeting with a new Scrum team which already had business/analyst, before transitioning to Scrum, who was designated as the product-owner (PO). He was one of the most participating attendees in my Scrum class which I deliver to more than 150 employees. Read more…
iBacklog
In implementing Scrum, we create a team Improvement Backlog. The items in this iBacklog can be:
1. Organizational impediment: This is an organizational change, for example, to create a new role called Product Owner as the single point of contact to the team.
2. Infra-structural improvement: The adequacy of Definition of Done is limited by the infra-structural for the development. For example, ability to make hourly build and integration of code lines from various teams.
3. Team practice to be implemented: Team practices include self-organization, collaboration and empiricism. This is in addition to engineering practices.
4. Scrum ceremonies
5. Other teams coordination
To quickly boot-strap Scrum implementation in a team, I found that prioritizing the iBacklog and starting as soon as we can increase the chances of success in implementation. For example, there may be 1-2 organizational changes to be resolved, then we agree on Definition of Done, then implement Scrum ceremonies directly.
If we succeeded in implementing the ceremonies, Scrum will help in surfacing more improvement opportunities during retrospectives and other Scrum control points. Scrum Master or coach should maintain this iBacklog with the same rigor the Product Owner maintains the product backlog.
Embedding Scrum in Kanban board
In a typical maintenance project managed using Visual board, we can have cards representing bugs, enhancements, new features or new product development. All card types can be managed using the value stream of the visual board except for new product development (NPD). The NPD represents fundamental architectural change into the product leading to break through added features to the existing product. Such NPD card can be managed as Scrum project because of the following.
Long duration
A typical NPD project can take in average 10 weeks which is much longer than cards from other kinds.
Team effort
While a typical card can have one developer, for NPD it requires team.
Requirement management
NPD by definition means requirement will evolve and new discoveries about the product would occur from one iteration to the next. This kind of convoluted development activity would require highly iterative and risk oriented delivery of slices of the requirements.
Different value stream
The value stream for non NPD card is agreeable and visualized. The NPD can have a very different value stream and can employ different skills from the maintenance value stream.
Technical risks
NPD involves myriad of technical risks and can require substantial architectural and design work.
Management oversight
For NPD management and business users would require periodic review of the increment for feedback. In normal value stream though these review can occur but not to the extent of interactivity required for NPD.
Marketing analysis and ROI
NPD is driven by marketing and financial analysis of ROI. In additional to the technical product risk, there is also financial risks due to competition from other vendors. The revenue model is important for NPD and derives the prioritization of backlog of a NPD card.
Based on the above factors, I would recommend managing NPD card as sub-project using Scrum.
How to classify the card as NPD? Use the above factors as check list. Another rule: the card should be classified as NPD if the current value stream of the visual board fail to work.
What about code integration?
I suggest managing NPD card as separate trunk in the version control system. It can take multiple iterations before we can have shippable product, at that point we should start merging this trunk with the baseline product.
Kanban for Scrum Implementation
Two weeks ago I met a client, who is transforming to Scrum, his biggest concern was that people may leave!
Showing lot of respect to his opinion, I sensed that he had ever increasing attrition of developers. I stopped short from even mentioning what Scrum prescribes, though he was specifically asking to implement Scrum. I didn’t want to mention dedicated teams, freeze changes during the sprint or release planning, or other practices which I practiced and value.
Rather than being interviewed myself, I began to interview him. He had projects to be delivered at Fixed scope and Fixed schedule. He was worrying that a Scrum specialist would start pushing Scrum practices causing unpredicted impact on his environment.
For his surprise, I suggested that to hold our horses and don’t think Scrum or any other tool. I suggested to implement a gradual process improvement function that would allow solving the business problem he mentioned and continuously improving his capability to respond to customer’s varying needs. He was already preoccupied about using sprints, velocity, backlogs and other artifacts of Scrum. I suggested that he might like to consider Lead Time as the primary metric driving his continuous improvement activities. I emphasized that we don’t rule out the use of Scrum or any other tool.
Based on what we would discover we can decide on what to implement, instead of just go Scrum! Read more…
Product-Box (aka organization character)
Scrum Product Box 01
Scrum Product Box 02
It was interesting session during Deep Agile on May 15th, 2010, in Cambridge, MA which Lyssa Adkins facilitated to build a Scrum Product-Box® . A Product-Box® is one of the innovation games from
http://www.enthiosys.com/
. In this post I am giving my own reflections. The description of this game can be found in this book by Luke Hohmann.
This game helps the vendor to collaborate with the customer. The customer will design the product-box of the product which the vendor is trying to sell her so that she can resell to her end customers. The process of directly working with the customer and allowing her to design her own flavor of the product is so powerful. I found that the customer is hesitant to buy the product unless she can resell to her own stakeholders. This collaborative game early resolves doubts and risks and allows the vendor to have more understanding of the concerns of the customer.
Scrum Product Box 03
During the game, each attendee played the role of the customer to design her own product box to so that she can resell internally. The product was Scrum itself. Imagine the roles as The vendor (Agile consultancy) and The customer ( IT services in a large organization who are considering using agile/ Scrum). By designing the product-box herself, the customer in-fact formulates the story in a way that she can resell to her management.
The second phase of the game starts after the customer finished designing the product-box. The customer begins reselling her product-box to her own customers by describing the drivers for her design and the benefits to the organization as indicated by the product-box. The box at the top has attracted my attention. This product-box reflected waste removal as result of implementing Scrum by limiting the team’s commitment in fixed length Sprints and have team members do different things. This should have economical appeal from the perspective of the organization in addition to the promise of delivering something valuable every iteration.
Before playing the product-box, the team had identified the impediments towards Scrum implementation, please see the picture below. During selling the product-box, we related each design to how it can address the identified impediments.
Impediments to Scrum Implementation
It appeared during the selling session that each product-box is able to address certain impediments that are different from the ones addressed by others. This for me reflects the importance of design in selling our proposal to our organizations. The customer can make sure that her design addresses certain concerns that are particularly important to her organization. In other words, the product-box reflects the character of the organization.
The selling session is the most important part of the game. The customer is going to be challenged on the effectiveness of her product in addressing the pains of her organization.
Finally
If we know that we will be challenged by our organizations, then why should not we by prepared by creating a design addressing the impediments before attending selling session? Also, as a vendor we should put ourselves in the shoe of the customer and understand her situation and the requirements of the end user, who we don’t directly deal with.
