The Road to Agile Growth (again)
Posted on June 28, 2009
Filed Under Articles | 1 Comment
My lack of blog posts has not been for lack of agile interest, rather, it’s been because of the “tornado” we’re in at my company. We experienced high waves of growth in mid 08, followed by the horrible economic and market downturn in late 08, and, then, almost immediately followed by unbelievable growth and funding conditions in early 09. (Thanks President Obama!) The turmoil is exciting, yet stressful in itself (as the canker sore above my left upper canine is currently exhibiting).
The good news is that we’re on the upslope again. In his visit to our headquarters last week, Colorado’s Governor Bill Ritter recently put us in the “sweet spot” of the state’s new energy economy.
So, how does this relate to the Agile Product Owner’s blog? Well, because we’re in growth mode again, we’re once again thinking about how to best scale the organization for optimal software and embedded firmware efficiency, and always be one step ahead of the market. This creates opportunities for current and future employees, while it can also fashions discomfort of the unknown in the transition.
I’m a huge fan of Dean Leffingwell’s Scaling Software Agility blog. He clearly has his finger on Scaling the Agile Enterprise. However, as self-admitted in his Product Managers AND Product Owners post, most of the methods discussed are cultured from enterprise organizations. We’re still a baby-enterprise learning to walk/run. The challenge is, aside from just hiring the crap out of the huge unemployment pool and filling the holes (highly unmanageable and not recommended), how do you strategically grow the organization, and what are the most efficient transition/knowledge transfer/migration/ steps along the way?
Let’s start with the Scrum Team. I like this ideal scrum team architecture from Dean’s blog:
Optimal Scrum Team
While we have the characteristics (collocated, dedicated, focused, cross-functional, self-organizing), the teams are physically not organized as such… yet. It’s highly likely we’ll get there soon, as we are seeing the benefits to this team architecture.
So, my intention here is to document how we get there from here. Here are some of the challenges:
- 1 Scrum master serving 5 functional teams (ouch!)
- 0 Product Owners (or whatever the argued title is) as defined in this blog and many others. The role is there, however shared between product management and engineering management, and it’s stressing the process. (‘ak!’, you say, ‘how can you even be the Agile Product Owner without currently being one?’…’sigh, I know‘…I reply…)
- 1 UI designer software, 0 UI designers embedded
- 1 Sr. Architect
- 1.5 Technical writers and they don’t live in engineering
- 4-5 QA professionals, not paired directly with the scrum team
- Dozens of developers, organized in various teams
Aside from the obvious answer: ‘just reorganize and staff it’, what are the strategic and tactical steps we can do along the way to get there? Don’t know exactly, but I’ll share when I do. Let the journey begin…
Agile Product Owner/Agile Product Manager- Series
Posted on February 27, 2009
Filed Under Articles | Leave a Comment
For those of you still trying to weed through the APO/APM roles and responsibilies, I highly recommend Dean Leffingwell’s latest series on the subject. Dean takes an appropriate and mature enterprise view of how to grow or transition to the agile organization, even down to the most effective size and mix of teams for optimal efficiency. This team-based approach defines clear roles and responsibilities, and provides the cleanest definition between the two roles (I say roles, not titles!) that I’ve seen to date.
He also elaborates on the need for Product Owners by stating the following:
Further, as taught and commonly practiced, the Scrum Product Owner has additional, tactical activities that directly contribute to the team’s success. These include:
- Setting objectives for the Sprint (iteration)
- Prioritizing and maintaining the backlog
- Participating in the Iteration planning meeting
- Elaborating stories on a just in time basis with the team
- Accepting stories into the baseline
- Accepting the Iteration
- Driving release planning
That’s just a teaser. Be sure to visit the article. In the end, you’ll walk away with a nice recap of the critical duel, yet partnering roles the Agile Product Owner and Agile Product Manager play within the organization. Nice work Dean! Read the entire series here.
Agile ‘09 Open for Submissions
Posted on January 9, 2009
Filed Under Articles | Leave a Comment
I’m honored to be a reviewer for the Product Management stage at Agile ‘09. We are now accepting submissions. Submit your proposal on your real-world experience and guidance regarding Agile Product Management at:
http://agile2009dev.agilealliance.org/product
Deadline for proposals is February 13, 2009. Join us at the conference in Chicago August 24-28, 2009.
Can Use Cases Possibly be Agile?
Posted on December 30, 2008
Filed Under Articles | 4 Comments
I follow many blogs, including ScalingSoftwareAgility. In Dean’s latest post: Agile Enterprise Requirements Information Model – Subset for Agile Project Teams, he explores a requirements meta-model. That meta-model is void of Use Cases! That got me thinking “Hmmm…I’m working in an agile organization as an agile product owner, but I still write Use Cases when I feel the need to! I must be still living my former dark, SDLC (pre agile) life…!”
But, maybe not!
Let’s explore how Use Cases can help as a powerful tool in the agile requirements meta-model.
First and foremost, I employ use cases as my primary elaboration technique for the simple agile attitude of constant communication. Our team includes software, firmware, and hardware developers. At our mature stage of the game, all stories inevitably touch all developers, across all disciplines. While we would like to think we all agree, inevitably, we don’t. We are constantly having discussions like: “Should the logic be built into the end device, or the software platform”. “Should the data be pushed or pulled?” “What’s the persistence model, and how long/where should the data persist?” “What are the hardware memory requirements for this story?” Use cases help flush out answers to these questions, and help bring a starting “agreement” among developers as to the initial direction of implementation. That said, we are agile, and it’s all subject to change!
Let me step back and talk about the generic differences between Stories and Use Cases.
Stories typically fit on a card, and have a simple framework: “As a [type of user] I want to [perform some task] so that I can [achieve some goal]”
Use Cases provide a deeper analysis and a more detailed framework for how the user interacts with the system. Further, Wikipedia defines them as: “a description of a system’s behavior as it responds to a request that originates from outside of that system.“
I acknowledge that these statements provide generic differences, and we could go into detail on the specific definitions of these artifacts, but for the purpose of this post, I wanted to share how we are using use cases in our agile process, and why they work for us.
Why use cases work in our agile process
1. Initial Agreement to Final Agreement
Many Epics or Stories start with a picture or an idea. It’s usually a UI that Product Management has sketched, which defines what the user sees, and infers how the user shall interact with the system. This is often (but not always) accompanied with a story. Defining how the system behaves as a result of the user interaction is the challenge. Use cases provide the perfect forum to analyze and define this initial to final user to system interaction.
2. Statement of Record
Like I said, developers do not always agree (nor do humans for that matter). Use cases provide that simple statement of record for when our brains fail to remember how we thought through the main success scenarios and alternate success scenarios, as well as variations and open issues.
3. Developers Love Them!
A story is not DONE until it’s tested. Most “good” developers write their unit test before they even start laying down code. (some write them after). Use cases give developers a framework for their unit tests before they get going. That’s not the only reason they love them. Developers are often anal (forgive me, I love developers for this reason). Use cases give developers the opportunity to capture details that they feel are important to the story. Careful though…don’t let them get caught in “analysis-paralysis”. As scrummaster, allow discussions, and come to initial agreement honoring the fact that we don’t know what we don’t know, and move on.
4. Business groups gain early understanding
My philosophy is: “Publish everything, and have no secrets.” Our Wiki is golden. By publishing the use cases, all areas of the business gain early access and an understanding of how the system will behave. Stories can provide this same benefit, however, use cases give other parts of your business a “more than they need to know”, aspect, thus covering the proverbial ass and further opening up conversations. Also, this helps get documentation into the agile process early and often.
5. The perfect framework for user acceptance testing
Many conversations happen during the agile development lifecycle. If use cases capture the initial to final agreement per sprint and/or release, what a perfect framework for user acceptance tests (Agile Product Owners LOVE THIS!)
Best Practices for Agile Use Cases
Interview Stakeholders
Before you jot down a word, interview Product Management and the development team leaders. Knowing that the team will most likely not agree, this helps in gaining an initial understanding of what the open issues and what discussion points should take place.
Make them lightweight
No one wants to read use cases that are dozens of pages long. You’ll gain better readership by keeping them short. No longer than two pages should be sufficient to get going. (two may even be too long!). Capture just enough information to get the heads to nod and move on. Make sure you communicate in a language that is common to all stakeholders.
Keep detailed UI design out of it
I struggle with this one, as I am a fond believer in UI detail, but that’s not the goal. Having an exhibit or two with screen shots is fine. Making your use case into a detailed design document is not.
Present/collaborate with your team
Use the daily meet-after opportunity to elaborate and gain feedback. This daily opportunity allows for quick turnaround. Depending on the story, developers often need time to noodle on a use case. Asking them daily until confidence is built helps hedge your bets.
Design them for change.
A simple intro page with a change traceability table will most likely serve you in the future. (post mortems, refactors, etc.)
Write your Use Cases Just-In-Time
After interviewing stakeholders, most Product Owners can kick out a use case in an hour or so. This should happen JIT prior to Iteration Planning. Having a light-weight use case ready at the iteration boundary provides the team a clear framework for tasking and estimating.
Where could use cases live in an agile requirements meta-model?
Using Dean’s requirements meta-model, I took some liberties and bloodied up where “Light Weight Use Cases” could live. Note: they are optional!
Light Weight Use Case inserted into Requirements Meta Model
All this said, stories are part of our daily agile process too! Not all stories are elaborated with use cases. Some are clear as a sunny Colorado day. Use cases are brought into the agile process primarily when we want to provide that more detailed analysis of user/system interaction, and gain agreement across the system and developers. I simply employ use cases as another tool in my agile toolbox.
To learn more about agile use cases, follow the links to these sites: Ivar Jacobson, and Alistair Cockburn as well as Dean Leffingwell’s Scaling Software Agility. These use case and requirements gurus offer further agile techniques for applying use cases into your process.
Stand-up! And Pay Attention!
Posted on November 23, 2008
Filed Under Rambling | 3 Comments
The value of the daily stand-up is often compromised by team members who stand, but are not paying attention, nor participating in a proactive fashion. This may be because of personal distractions, lack of sleep, self absorption, or simply because their coffee or tea has not kicked in. Stacia Broderick has called it: daily standup withdrawal (DSW). To break this withdrawal from our daily best practice, I often invite an additional team member, who ALWAYS PAYS ATTENTION! Since his participation, I’ve noticed an increase in members asking for help. 
The Stand-Up Patrol
(Agile Product Owner does enjoy humor, on occasion. Hope you do too!)
How to be THE ULTIMATE Agile Product Team / Agile Product Managers and Agile Product Owners Living Together in Harmony
Posted on November 8, 2008
Filed Under Articles | 5 Comments
Forgive me team, but it’s been a while since my last post. My last blog was posted before I started applying agile methods within a new team. I’ve been enjoying the posts from enthiosys, and Dean Leffingwell’s Scaling Software Agility blogs, and sharing them with my product team. It’s interesting, as many of you touched on “when to adopt the Product Owner role.” There’s no perfect answer (budgets usually preside), except to adopt the attributes, and to grow the role as the company grows. As you can expect, there’s been some lively discussions within my own Product Management/Engineering teams as well. Now that we’re maturing, and IMHO “qualifying” as a real agile team, I’d like to share some of my experiences with applying Agile Product Ownership, and Agile Product Management within our organization, in an effort to become THE ULTIMATE Agile Product Team.
First, I’d like to step back to the ever-evolving definition of the Agile Product Manager (APM) and the Agile Product Owner (APO).
The following chart is a super-set of data that I’ve compiled from a few articles noted here. This chart defines the attributes that resonate with APO/APM roles that I’ve held:
| Agile Product Manager (APM) attributes | Agile Product Owner (APO) attributes |
| Tracks industry trends | Tracks internal cadence and deliveries |
| Defines release objectives | Defines iteration objectives |
| Provides overall strategic direction | Provides day-to-day tactical direction |
| Delivers business level use cases or stories | Provides system level use case or story elaboration |
| Has a solid understanding of current solutions | Has an understanding of architectural component and subsystem design |
| Defines external roadmaps | Defines user acceptance tests |
| Manages release and portfolio priorities and backlogs | Manages the iteration and cross project priorities |
| Manages the changing needs of the market and customer base | Unblocks and focuses the portfolio or feature teams throughout the iteration |
| Manages market messaging and positioning | Manages defect scheduling |
| Provides the overall vision | Provides the implementation |
| Lives in Marketing | Lives in Engineering |
| Communicates daily with the Product Owner (shares a brain with the PO) | Communicates daily with the Product Manager (shares a brain with the PM) |
| Delivers The Release | Delivers The Iteration |
While these are not concise nor deep definitions of what the APM/APO roles are, I will elaborate on how the cadence of an Agile organization alone helps drive the need for this separation of roles. I discuss our cadence and need below.
Before I move to cadence, I touched on the timing of growing of adopting Product Owners. In my current organization, there was an immediate need for a Product Owner. At first, it was called the “Agile Project Manager”. Regardless of the title, the role was the same. At the time, we had one Product Manager, who was completely overloaded. He was out of the office 80% of the time gaining valuable customer and market feedback on a new product. When he was in the office, the remaining 20% of the time did not account for direct collaboration with the development teams. The product development suffered in many ways: lack of story elaboration, lack of iteration prioritization, softness of iteration boundaries and cadence, etc, etc. So, the Project Manager (aka: APO), organically took on the role and attributes of Agile Product Owner, and immediately helped the team stay focused and deliver the iteration.
As our product portfolio grew, so did our product management team, and inherently, the need for product ownership grew as well. However, as mentioned above, budget doesn’t always allow for a 1 to 1 APM to APO role, so we quickly “grew” product owners within the portfolio solution teams that participate and communicate up through the Scrum of Scrums and other daily scrums. These Product Owners shared roles with Sr. Software Developers, System Engineers, and Project Managers. Regardless of the title, the role was required, and the team stepped up to deliver some of the Product Owner attributes and tasks as defined above. Below is a snapshot of our engineering cadence and communication channels that fostered the agile growth:
You can see that the 1 week cadence alone drove the agile best practice of constant collaboration and communication. With this market-driven cadence, there’s absolutely NO WAY an Agile Product Manager can balance their strategic external dependencies with the daily needs of the development team, and still be effective at their own external facing role (as effectively voiced by the Cranky Product Manager). (I Love Cranky PMs) This engineering cadence allowed for and “forced” the product deliveries necessary to maintain market leadership. Having both APMs (when they can) and APOs (mandatory) at these meetings fosters the mind-meld required to drive at a sustainable agile speed.
This looks logical, right? However logical it may seem, creating the Ultimate Product Team does not come without emotional challenges of adopting, coaching, and nurturing this high-performing teams. Past processes, roles, and behaviors do not change overnight, and people are not always willing to change their behaviors to accommodate a “supportive and holistic team-based approach” to delivering product. Here are some tips I’ve learned to effectively integrate the APO/APM roles into becoming The Ultimate Product Team.
Collaboration – Create an iteration cadence that supports daily collaboration. Allow for all meetings on the engineering cadence to be “Open Door”. Product Management will be selective in choosing the scrums or meetings that mean the most to them at the time. If Product Management cannot attend, Product Owners should summarize high-points in an email or minutes. Minutes should be posted to the Wiki of choice so that anyone can easily catch up.
Partnership – Partnership between APMs and APOs are requisite. One partnership tactic I use is to constantly ask my Product Managers; “How can I help?” For the most part, this tactic works well, and Product Managers are more than willing to take you up on it in a heartbeat. Go out for coffee once a week. Meet after stand-ups for a few moments to see if anything stood out as needing attention. Synchronize and communicate the ever-changing corporate priorities daily. Feel free to pop into each other’s cube/office whenever you need to
Trust – The true foundation of building your ultimate team is to trust your colleagues and APM/APO partners to make the right decision. Be forewarned, that your APM/APO partner will sometimes make a decision that is opposite of yours. Both parties must always understand the priorities. Stand behind each other, and support each other’s decisions, so that teams know you are both empowered, and can be trusted to have the same overall business decisions and authority.
Try implementing just a few of these techniques into your organization as you adopt and grow your own Ultimate Agile Product Team.
Scaling Software Agility - A new one day course!
Posted on February 2, 2008
Filed Under Rambling | Leave a Comment
Dean Leffingwell is offering a one-day course based on his book: Scaling Software Agility.The next one is November 13, 2008 in Boulder, Colorado. Register here.
If you’re a software development director, manager or team lead; software developer, tester, architect, or in QA , and have an objective to provide a step change in the productivity and quality of the software development process but are faced with the challenges of developing software on an enterprise scale, than this one-day course is for you.
This course is sponsored and offered through Agile University. For more information, visit Scaling Software Agility: Best Practices for Large Enterprises - A One-Day Course
Let me know how it goes!
Applying Agile with Firmware Development?
Posted on January 3, 2008
Filed Under Rambling | 1 Comment
As I close the door on one long term rewarding and environmentally worthy agile contract and open the door to a new agile product owner opportunity, I am faced with a new challenge of integrating a firmware device into an agile process. Let me share my ideas, and I’ll later check back with you and report on how these ideas pan out in real life.
First, agile is not a process. Agile is a set of principles and ideas that are combined to deliver software in a swifter, more customer and people-focused manner. One of the things that I like about it is that it is not overly prescriptive, rather, it allows for individual business tailoring. In other words, it uses people to respond to change, and adapt to a particular challenge.
So, as I’m faced with the integration of firmware into a newly formed agile software development environment, my thoughts on how to apply agile ideas with our firmware development are as follows:
- Integrate the firmware deliverable timeframe as a benchmark into the release roadmap
- Monitor the deliverable, and report status to the team in daily standups and meetafters
- Create simulation scripts or mockups of firmware functions to simulate the firmware’s behavior. While we cannot test the actual device, we can certainly test the defined logic and flows.
- Set an objective to “integrate and test” as soon as the real firmware is available. This may be a moving target, but it still sets the expectation to be ready and adapt.
While we cannot apply continuous integration and test to what we don’t have, we can certainly create mockups of behavior, plan to adapt the iteration cycle for this deliverable, and fully integrate and test as soon as it is available.
Give me a release cycle or so and I’ll report back! Of course, please comment if you have some good advice. I can use it!
Applying Agile Product Ownership within Teams
Enterprise Product Manager=Agile Product Owner…I don’t think so…
Posted on November 19, 2007
Filed Under Articles | 14 Comments
By Jennifer W. Fawcett, Agile Product Owner Coach, agileproductowner.com
There are reasons and roles within a successful team that allow this to work (even if it’s not completely agile). I advocate that are two product-related roles within an agile enterprise:
- The Enterprise Product Manager, who typically reports into marketing, and who owns the RELEASE
- The Agile Product Owner, who typically reports into engineering, and who owns the ITERATION
Let’s define the responsibilities of these roles a little further. On the surface, Product Managers may look like Product Owners, right? Not necessarily in an enterprise agile environment,
Let me review the fable of the Chicken and the Pig, which is often used in the daily Scrum. The chicken suggests that the two involve themselves in a scheme involving ham (or bacon) and eggs (some suggest a breakfast, others suggest a restaurant). In reply, the pig always notes that, for the chicken, only a contribution is required (as a chicken can simply lay an egg and then resume normal activities), while for the pig a “total commitment” (or total sacrifice) is needed (as in order to make ham or bacon, the pig must be slaughtered).(1)
So, if pigs are committed, and chickens are Involved, which role do product owners and product managers play within an organization who has adopted the gospel of Enterprise Agile? Let’s look at the roles with the perspective of releases, and Iterations.
Product Managers have extremely full plates. Not only to are they responsible for the 4 P’s (Product, Pricing, Positioning, and Promotion), but as described above they are responsible for delivering product to market. They worry about the big picture, live in the future, and are always thinking “what’s next”. Product Managers are Committed to the Release. At the Release level, they are pigs. Product Owners are Involved with the Product Managers and the Development Team’s success through the Release, and at the Release level, they are the chickens.
Product Owners are committed to the Iteration. They live in the present, and are deeply involved in the product’s day-to-day evolution. They have a dotted line between Product Management and Product Development, and act as a communicator or conduit between the two teams. The Product Owner must have a deep understanding of each story, and demonstrate the ability to communicate details to the development team. Product Owners know that Product Managers don’t have time to dive into the details of each story for each iteration. Therefore, their job is to involve to Product Management enough to the get the level of detail and elaboration necessary, and then to further elaborate stories for development in time to meet the iteration boundary. At the Iteration level, Product Owners are Committed, and are responsible for the success of each iteration. They are the pigs. Product Managers involve themselves enough to communicate and prioritize the vision of the release, but at the iteration level, they are the chickens; Agile Product Owners do not replace Enterprise Product Management in any way; rather, they empower Product Managers to better deliver future market strategy and prioritized release requirements by enabling a full commitment at the Release level.
In my first paragraph, I alluded to some not-quite-so-Agile Product Managers. How did we get a product out the door without the entire team adopting Agile? The success was via the Commitment of the Agile Product Owner to the iteration, and the Commitment of the Enterprise Product Manager to the release. Even in a non-agile organization, the Product Manager always has a commitment to the organization to deliver a product to market so that role has always been clear and predates any agile transformation. This commitment is driven by the financial impact to the company of a successful product, and probably to the Product Manager’s paycheck. However, it is the new role of the Agile Product Owner that helped to enable both Development and Product Management’s success by committing himself deeply into the Iteration, living in the day-to-day collaboration and communication between Development and Product Management, and freeing up Product Management to work on the commitment to the vision and future of the product.