Scaling Software Agility - A new one day course!

Posted on February 2, 2008
Filed Under Rambling | Leave a Comment

Dean Leffingwell is now offering a one-day course based on his book: Scaling Software Agility. The first one is being offered in London, England on February 27, 2008, and a second in Boulder, Colorado on March 19, 2008.

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 | Leave a 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:

  1. Integrate the firmware deliverable timeframe as a benchmark into the release roadmap
  2. Monitor the deliverable, and report status to the team in daily standups and meetafters
  3. 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.
  4. 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 | 8 Comments

By Jennifer W. Fawcett, Agile Product Owner Coach, agileproductowner.com

I’ve seen agile work, first hand. I’ve seen an entire product development team STOP development on one fully beta-almost GA, totally-cool consumer-based web product, and begin development on an entirely new consumer-based web product (new direction, new concept, new codebase, new development language), and deliver that new product to consumers in 16 weeks. I’ve seen it work despite Product Managers who don’t quite understand agile, even though they work with agile development teams. Basically, I’ve seen miracles with agile.

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:

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,

The Product Manager’s goal is to deliver products to the customer, based on customer needs. While this is an over-simplification of what Product Managers do on a day to day basis (we know they provide the vision, prioritize the work, analyze the market, provide pricing, promotion, packaging, etc), delivering quality product to market is their primary objective.

The Product Owner’s goal is to deliver upon the Product Manager’s commitment to the release plan. The Product Manager represents the customer, and is also the customer to the Product Owner. Product Owners literally “live” with engineering and write and elaborate stories, to make sure the features of the release are met and demonstrable, on a prioritized feature by feature, story by story, and iteration by iteration basis. These two roles have direct impact on the success of a release, and both are needed within an enterprise agile organization.

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)

The chicken and pig persona is commonly used to describe the roles in agile teams. Pigs are totally committed to and accountable for the project, and are generally bonused (or sacrificed) on the financial outcome of the project. Chickens, however consult on the project and are involved on the project, enough to know the status or timely information as to the project’s well-being. (I have to also note the Rooster, who is really of no value, but likes to give advice none-the-less).

All agile teams need chickens and pigs. Pigs are Committed, and Chickens are Involved. This Committed/Involved paradigm allows for shared ownership and accountability, and is one of the foundations of a successful enterprise agile organization.

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.

Chicken and Pig Roles at the Release Level
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 Managers
Chicken and Pig Roles at the Iteration Level
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.
Product Managers
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.

(1) Wikipedia

Welcome to AgileProductOwner.com!

Posted on November 10, 2007
Filed Under Articles | Leave a Comment

Welcome to AgileProductOwner.com. Our mission is to share real-world stories and insight on how Agile Product Owners fit into an Agile Software Development environment, and the value they play in increasing software development velocity.