The weak links of Agile value chain (part 2 of 2)

Rapid shrinking of the time window separating new product release launches imposes pressure on functions outside product development. Consider for example, if development learned how to roll out a new product release every 90 days, continuing to target education content refresh 60 days after product GA no longer makes sense. Sales, services and support teams - all have much less time to get up to speed with latest changes and advancements in the product to stay ahead and be ready to provide solid quality experience to the company's customers.

Similarly, other teams may be impacted on the front end of the shortened product release cycle. User interface designers for instance will no longer have ample time to iterate new wireframe designs ahead of the development phase. Some UI design teams in an effort to be relevant will attempt to integrate into the scrum teams, others will struggle to maintain functional independence at the expense of their ability to stay relevant.

Any company engaged in complex activities aiming at growing sustained and profitable business can be represented by a chain with each link representing a different function within the company. Each function plays a critical role in delivering the winning end-to-end customer experience. Software product development is just one of such links, hence the company-wide benefits of adopting Agile methodology by this team alone are constrained by the rest of the company remaining outside of this transformation.

It goes without saying, the chain is only as strong as it's weakest link.

The weak links of Agile value chain (part 1 of 2)

Achieving successful adoption of Agile software development is no easy fit. Numerous organizations embark on this journey, investing significant energy and resources attempting to transform. Proven rules and best practices are challenged, the foundation of established organizational knowledge is questioned. Teams are sent to training classes, Agile coaches are hired, t-shirts and mouse pads with morale boosting statements distributed, managers have their annual performance objectives adjusted...

Not every organization is successful in this endeavor though, particularly when it comes to large scale software development and impatient investors and executives. Only few are destined to experience the freedom of creating value, unencumbered by waste. Only some will embrace the uncertainty of software development innovation.

When all is set and done however, the big gotcha is waiting for those who cross the finish line and deserve our tip of the hat.

Successful adoption of Agile software development will inevitably shock your existing customers, your sales force and finally the rest of your company who will now have to deal with the consequences of

1.  accelerated rate of new release introductions
2.  the fit of every delivered feature with market demand

While watching your customers coming to grips with this windfall may be gratifying, and will surely be followed by recognition and appreciation, the real challenge lies in how the rest of the company adopts to this faster go to market pace, and ultimately how can this be translated into a profitable and sustainable growth for your company.

What can help you getting promoted

I attended this morning Boston Product Management Association's 2013 Mentorship program kick-off and one of the round table topics discussed was related to factors contributing to getting promoted in your job.

Here are some ideas floated, in no particular order:

• Be conscious of where you've come from into Product Management and grow to be a well rounded business person. If you are formerly an engineer, reach out and make some friends among sales, if you've come from support delivery learn how development and marketing operate and what matters to them. Try to avoid getting labelled as single-dimension expert.

• While we are at this, develop a reputation for being a Subject Matter Expert (SME) in several fields relevant to your company's business. Make sure people know and value your knowledge and come to you for advice. This can be a particular technology or field of research, industry, set of standards, social media, market research, methodology such as Agile, vendor management, pricing strategy, etc.

• In general market yourself within the company, particularly if you work for a large company. Reach out to other functions, teams, business units, projects. Show genuine interest in what they do, offer help, create synergies. Get engaged in initiatives outside your main day to day project(s). That's a good way to get to know more people outside your primary circle, and get them to know you. Finally, make sure your contributions are known to more than just your immediate manager, also to his manager and/or peers.

• Many people have ideas and can talk about possibilities. Differentiate by picking something meaningful and succeeding at delivering results that everyone can see.

• Learn to be comfortable and communicate effectively with both senior executives, all the way to CEO, as well as with rank and file employees.

• It's always easier to get promotion when you have already been doing everything the new position calls for. In other words, don't wait to be asked to perform new duties. Recognize the need and opportunity and start adding value to your organization. Help your boss and he will appreciate and find ways to recognize you.

• Promotions come in different flavors. If your company does not currently have an opening to manage (more) people, you can still be recognized and promoted as an individual contributor. More and more companies understand the need to attract and keep top talent and are becoming increasingly creative about ways to satisfy career aspirations of their high achievers.

• Even if you don't get promoted soon enough at your current organization, you will begin developing a reputation that will serve your long term goal and ultimately put your career on the right trajectory. Fast forward 5-10 years in the future, when you apply for that coveted VP job, your recruiter will be searching and talking to your current boss and colleagues about you.

• Finally, be ready to recognize when there is just no room to grow in your current organization. Let's say you are in a small start-up that is not growing particularly fast, and your boss is one of the founders. In situations like these quitting is not necessarily losing, it may just be the right step to take you closer to the promotion you are looking for.

What is your experience? Can you add to this list?

Keeping the batch size small

I am reading the book called Lean Startup by Eric Rides and one particular idea resonated well with my recent experience.

I noticed a pressure coming from around me to lengthen our 3 week long sprints (if only we could add one more week we could complete more valuable complex stories) and/or lengthen our release by adding one more sprint (we need more compelling release content). While different arguments are used to justify these calls - its all boiling down to attempts to increase the size of our our "production batch".

By now my intuition strongly points me to keep the batch size small. I know it will help to keep the level of waste down. However in the heist of debate I sometimes look for ways to describe why the small batch size is important, in simple layman terms.

Here is the story from the book that I found helpful.

The guy placed the bet with his daughters that it will be faster to fold 100 letters, place them in envelopes, seal and affix a post stamp by doing one envelope at a time (small batch size of 1) vs. folding 100 letters, then stuff 100 letters in envelopes, then seal 100 envelops, then affix 100 stamps (batch size of 100). The guy won the bet as the girls didn't at first realize the increased cost of dealing with larger batch size (e.g. keeping a stack of 100 envelopes from falling to the floor) and the cost of making a mistake when it gets magnified by the size of the batch (e.g. incorrectly folded 100 letters that don't fit into envelope - all 100 have to be redone instead of just one).

Falling back to the old habits

Just as I thought I've mastered truly agile approach to product management, I noticed myself slipping back to old bad practices: not delivering user value that can be validated by the end user at the end of the sprint.

My scrum team has recently delivered a large epic over several sprints. While I helped the team to break down the original large story (epic) into smaller stories that could fit into each sprint, I could not convince myself to demonstrate what the team has developed at the end of the first sprints to our customers. I doubted our team's work, while instrumental in laying the foundation for the ultimately delivered value, would generate enough interest or even appreciation among our end users.

On one hand, the ground work delivered at the early stages is just too low level (think of plumbing) for many end users, often lacking visible end user facing benefits. On the other hand, I was wondering if prematurely exposing incomplete value package would expose flaws in existing products customers may be unaware of and cause them to doubt what they have instead of appreciate what's coming.

I also noticed I am not alone facing the pressure to concel my yteam's progress, and skip the end of sprint demo. Other Product Owners sometimes tend to avoid showing incomplete features, hoping instead to delight customers and get rave reviews for well thought out, polished features shown to customers at the end of several sprints worth of effort.

Doesn't this push us back to the old dark age of waterfall?

What do you do to avoid falling into the same trap?

Collaborative Efforts Drive Innovative Results

Here is a blog (published at CA Communities web site) that includes the interview with none other than... me! :-)

http://community.ca.com/blogs/innovation/archive/2012/09/13/collaborative-efforts-drive-innovative-results.aspx

Product Launch (3 of 3): Quality vs. TTM

The not so trivial challenge of "secrecy vs. openness" is further complicated by the collision between our genuine desire to keep improving the quality of the new product at the expense of launch delay with the business critical time to market pressure. Inevitably executives/investors and sales want the product released sooner while the product team needs more time to add features and address any known defects.

While the differences between consumer and B2B markets affect product launch strategies, at the end of the day I have to agree with Eric Ries who advocates in his book ‘The Lean Startup’ - a methodology for continuously testing your assumptions as you bring new products and services to market, whether in a start up or in a traditional large software vendor company. A few chapters in and this is already resonating... The Lean Startup methodology is all about that - getting early versions of the product (what the author calls the ‘Minimum Viable Product’) into customers hands and empirically validating (or refuting) your assumptions about what they want, rather than spending months designing and building something that misses the mark...

I used to wonder how can the big companies (that seem to be taking calculated risk in introducing something really new to the market, like iPad for example) take the plunge and launch their products early enough, let alone earlier than expected. Just imagine new Windows OS came out earlier than planned simply because Microsoft wanted to get early customer validation…