Sunset at the derby party

Product Owner, "A Day in the Life"

Fan the seeds of innovation

When a company is just starting out, it’s all about finding something that resonates with users and delivering real value to customers. It’s why startups are such great places for innovation. But for those skilled or fortunate enough to accomplish that, as the company starts to grow, very often the nature of the product organization changes into a group whose main purpose is to serve the needs of the many stakeholders across the business – business owners, sales, marketing, business development, legal, finance, operations, customer service, etc.

The job of the product manager then devolves into one of documenting stakeholder requirements, mediating conflicting objectives, and allocating the limited developer resources to try to satisfy as many of the stakeholders as possible.

Is it really any surprise that innovation stops? Is it really a surprise when your most talented and creative people leave for another startup, while the ones that remain are willing to spend their days running from stakeholder to stakeholder trying to negotiate some kind of agreement?

Now, of course there are always very legitimate business requirements that have to be addressed and accommodated. Supporting contractual obligations, monetization opportunities, and addressing operational issues are all very real examples.

However, many product organizations become so overwhelmed with these urgent day-to-day stakeholder obligations that two even more important responsibilities are pushed aside. The first is the focus on the actual customers and their needs; and the second is the future of the company and what it takes to provide sustained differentiation and ongoing sources of revenue and value.

Strong product organizations work to strike a balance between those things required to keep the business operating, and innovating on behalf of the customer.

Product organizations must achieve this balance otherwise they cease to provide the role that is needed. In some companies, especially those with strong business owners or strong senior executives, others will feel they need to step in and try to fill this void, and it’s hard to fault them for that.

After years in this situation, the problem becomes cultural and institutionalized, and the product organization is not empowered, rarely even respected, and of course they are frustrated.

Fortunately, this situation can be corrected although it’s not a simple change, and it requires sustained and strong leadership.

It starts by having the product organization earn the respect of the company and its leaders, and this won’t happen until the product managers become the recognized expert on the company’s customers and users. And this of course means reconnecting with your customers in a big way.

Once you’ve done this, and leaders from across the company seek you out because of your understanding of the customer, then you’ve earned that seat at the table, and now you can bring the opportunities that you have discovered during your intense customer interactions.

I don’t mean to oversimplify what it takes for a product organization to regain its mojo; I’ve got another article brewing on a set of steps to achieve that, but for those of you that feel trapped in a product organization that lives to serve the company stakeholders rather than your customers, and I know there are many of you, I hope you will take a look at your roadmaps and backlogs and ask yourself which of those items are actually serving the customer and have a chance at delivering real value for your company?

Enterprise apps need more focus

An interesting article by Stuart Leung:  http://bit.ly/OFfsAk


"Despite the increasing usage of mobile devices in the workplace and the fact that enterprise apps earn up to 4x that of consumer apps, the B2B app market is still lagging behind."

Kentucky Basketball madness!!!

From the basketball courts point of view:  http://vimeo.com/m/91129210

From the fans point of view:  http://replays.ncaa.com/tc/217199?autoplay=true&h=324&ss=&w=435

Cherry trees in spring

That seems obvious ...

A perfect example of team collaboration versus waterfall management. We should all strive to get out from behind the deck.

http://m.tickld.com/x/engineers

Spring is here!

Introducing LAFABLE

Interesting post from Mountain Goat Software via a new site:  http://lafable.com/
Have a great April fool's day!

The long list of Scrum Master responsibilities

Retrospective ingredients continued...

Kaizen vs Retrospectives

In Kanban, Scrum retrospectives have been replaced with Kaizen meetings (kaizen in Japanese means “continuous improvement”). The difference is subtle but powerful. We have Kaizen meetings every two weeks; engineers and product owners discuss how the process should be modified to improve velocity and quality, while reducing overhead. Instead of looking back and critiquing what we did, all the energy is forward-looking and focused on process improvement. Defensiveness down, collaboration up!  

Everything in the process is fair game and any new idea is treated as an experiment to be tested. Most ideas are given a try, and very few are shot down. As a result, kaizen meetings have an upbeat, creative feel and the process runs very smoothly.

The risk and rewards of Kanban

Kanban isn’t perfect
We’ve successfully moved to Kanban and are really happy with it, but it’s by no means a perfect solution.

The Software Tools For Kanban Are Nascent
We use and love Atlassian Jira and Greenhopper. They have some nice Kanban features, but their Kanban board is relatively new and lacks the planning coordination we so hugely desire.

Loss Of A Systematic Focus On Urgency
With Scrum, that sprint clock ticks loudly. Everyone feels the pressure to get their work done before the sprint ends. Urgency is baked in. In Kanban, urgency is more abstract and doesn’t have quite the same emotion pressure. We’ve had to impose a sense of urgency in our team through culture and management—harder but hopefully healthier.

Keep Calm and Kanban
Kanban’s power comes from its focus on getting fewer items out faster through work in progress limits. Like anything, it’s not perfect and it may not be right for everyone in every situation but ultimately, we ended up with a happy team, higher productivity, less tension between the business and engineering, higher quality software, and A LOT less overhead. Win!

7 Habits of Bad Bosses

1. Poor communication skills
2. Bad judgment
3. Inability to lead teams
4. Problems in relationships
5. Poor conflict resolutions skills
6. Inability to manage themselves
7. Inability to learn from their mistakes

6 Baseline questions regarding scrum

Click Here to the main article

1. What’s your elevator pitch for Scrum and agile software development techniques?
1. Help people build software in 30 days or less.
2. When you were initially coming up with these concepts, did you ever envision that the methods would become as pervasive as they have?
1. We, (Jeff Sutherland and Ken Schwaber) came up with it for our own survival, and then we experimented with it in a number of companies that we were in. I would have never guessed. But I view Waterfall as the worst thing that ever happened to our profession, ever. So I’m delighted that it happened.
3. Why was Waterfall the worst thing that ever happened to the profession?
1. It starts with the expectation that you can take complex technology, people, and changing requirements, and you can predict exactly what they’ll be a far point in advance, and you put someone in charge of it that tries to maintain and stick to that plan. 
4. Are Agile and Scrum techniques equally applicable to other areas of business, and life?
1. David Starr runs his family using daily Scrums and weekly planning meetings (PDF). A sales operation is run by Scrum. They lay out the yearly goal, and then every month they lay out what they’re going to try to do, they look and see what they were able to accomplish, they adjust the business accordingly, then they move forward. The only thing that wasn’t done with an emperical, iterative or incremental approach was software! Which is the most complex of them all. It’s so weird.
5. What’s the biggest mistake that a company makes, or a software development team makes, in trying to implement these principles?
1. We’re trained in our organizations to believe that there’s someone in charge, who has people working for him, and he can tell people to do things and it will happen.
2. Companies think that people’s creativity can be mandated.
3. The hardest thing is to get the manager to see that his or her job is to see, what is the best the team can do, and help them do it, rather than get them to do what the manager thinks they should do. Anyone who’s been a parent knows exactly this problem with their kids.
6. How do you balance the need to collaborate with the need to concentrate?
1. People think opening up space and letting the noise vibrate is collaboration. Having people so you can see them, and go over and start writing on a board, or you can get the people you need right there, that is collaboration. There’s often a mistake that this ominous noise is collaboration. Visual cues and access are the keys.

Agile Consulting

I thought this was a great advertisement for consulting services.  

Franklin Theater

Franklin Theater

Ingredients for a successful Retrospective

Over the years I have had the opportunity to conduct many Retrospectives and lessons learned sessions.  Admittedly, some have went extremely well.... and others were lacking the original zest or spirit of the ceremony.  At times the meetings were perceived as punishment rather than opportunities to improve.  None-the-less we as a group pushed forward, looking for topics to highlight and possibly squeeze out some beacon of light to reassure us we were doing the right thing.

I have made a point to express my gratitude for the concept of Retrospectives.  The ceremony itself should not be taken for granted.  I have worked at several other companies where the primary focus rested soled on the term productivity.  Although I am not diminishing the the importance of velocity within the workplace, I am excited to see a company invest in itself and its employees by setting aside time for everyone to look at ways to improve.  It is for this reason, I have taken this event so personally.  If someone was going to invest time in me and my work, then I want going to take advantage of it.

Throughout this journey I have since discovered monotony and retro fatigue is a universal problem.  Many coaches struggle with finding creative ways to keep their teams engaged and the retrospective successful.  I have found a few universal themes that should be considered to combat a disastrous event.

• Time box the event.  Preferably 60 minutes max.  However if you do not need the entire time call an end to the meeting.
• Have an agenda advertised.  Issues do not magically appear the day of a Retrospective.  Make the retro agenda a dynamic list everyone can engage at any time. Sometimes there are surprises, though often the subject has at least some notion of where things are not going great.  This will help stimulate collaboration and remove selective amnesia on the day of the retro.
• Turn the computers off.  Removing distractions from the meeting will assist in keeping everyone focused on the discussion.  I am a strong advocate of collaboration.  There are several proven techniques to encourage collaboration and ensure even the most introverted disposition has a voice.
• Solicit feedback regarding the coaches performance.  Recently I had the opportunity to participate in my own Personal Retrospective to evaluate current performance as an Agile Project Manager and Coach.  It was humbling to hear coworkers who I respect greatly speak both positively and critically of my role.  In the end though, I was appreciative of the feedback as it worked to quiet the distracting internal voice of insecurity and help me focus on the team members perspective. Additionally, it helped me understand where I have been dropping the ball, along with recommendations on how to get on the right track.

The benefits of dividing a project into phases

I ran across a SlideShare presentation highlighting the art of storytelling within UI/UX development. Although the presentation was structured on storytelling, it reminded of the importance of dividing our projects into phases in order to better facilitate a workflow. By setting up smaller defined iteration cycles (aka phases), you promote transparency, the opportunity for constructive critiques and an overall environment for everyone to excel.

No matter whether you are building a small webpage for an upcoming event or a complex architectural software redesign, all designs goes through the critical phases of conceptual design, design development, implementation and refinement. Whenever entering a project be mindful your enthusiasm doesn't cause you to skip one of these critical milestones. The distinct differences between each phase allow for constructive critiques and feature sign off.

The precise idiosyncrasy of engineers have a tendency to make exact calculations every time they are faced with a problem. Designers will encourage iterations allowing multiple opportunities for mistakes or flaws in the design to present themselves. Sometimes it is difficult to identify the engineers from the software designers when you work at a software company. By identifying realistic goals and shorter iteration cycles we can provide the framework for everyone to flourish within an Agile environment. We should be looking for ways to create an environment for both dispositions to shine.

Credit to Anna Dahlstrom for the slides:  http://www.slideshare.net/annadahlstrom/designing-around-storytelling-digital-pond-london-06-feb-2014

Performance Reviews

Performance reviews tend to be a very tricky endeavor for most organizations. Recently our development group has started embracing the attitude "performance reviews are not helpful, feedback is".

Several examples have been highlighted as out conversation has evolved to reflect the disposition of our development group. They are:

http://www.jrothman.com/blog/mpd/2014/01/performance-reviews-are-not-useful-feedback-is.html

https://www.linkedin.com/today/post/article/20140206114808-15893932-how-adobe-got-rid-of-traditional-performance-reviews?trk=object-title&_mSplash=1

As we look to understand effective ways to conduct "reviews" the theme that has evolve can be summarized best as, "Don't get rid of performance reviews; do them all the time and let teammates own their job role."

Scope Creep

The biggest problem that most ScrumMasters face is defending the team from Scope Creep. We are going to have some strategies for defending your team and product. - Rod Claar, CST

Portfolio Pics

The value of Mentorship

By separating developers into Newbies and Veterans, we create the psychological incentive to explore more of the code base. Ambitious developers quickly want to shed the Newbie label and fully participate in the rest of the team’s work. However, by starting out by becoming an expert in one part of the system, the Newbie can quickly gain confidence in their ability to participate and make a meaningful impact on the system.

Google article

I recently read an article from Harvard Business Review.  http://hbr.org/2013/12/how-google-sold-its-engineers-on-management  I wanted to share a few highlights, I found to be universal.

Project Oxygen was always meant to be a developmental tool, not a performance metric,” says Mary Kate Stimmler, an analyst in the department. “We realized that anonymous surveys are not always fair, and there is often a context behind low scores.”

Therefore we created upward feedback survey (UFS)

People ops designed the training to be hands-on and immediately useful.  In “vision” classes, for example, participants practiced writing vision statements for their departments or teams and bringing the ideas to life with compelling stories. 

In 2011, Google added Start Right, a two-hour workshop for new managers, and Manager Flagship courses on popular topics such as managing change, which were offered in three two-day modules over six months. 

“Engineers hate being micromanaged on the technical side,” he observes, “but they love being closely managed on the career side.”

People don’t quit companies—they quit managers.”

I did not bring you here to teach them.  I brought you here to help them do their jobs better."