Author Archives: Kim Page Gluckie

  • -

Lessons from a 10-Year Long Product Backlog

Tags : 

Product Backlog Management Tools: When & Why?

I am often asked, “What tool should we use for Scrum?” or “What tool would you recommend for managing a large Product Backlog?”

Recently the Product Backlog question came up regarding a tool called CaseComplete, so I’d like to share my experience with managing Product Backlogs in complex product development.

The 10-Year Product Backlog Story

 In 2009, I was coaching an Agile transition with a large European software client who had 400 developers across 5 locations. We were using Excel to manage the Product Backlog (PBL) with 12+ Product Owners and it was very painful. The Product Backlog had 1200 items in it and represented 4 years of future work by the whole development organization.

Product Owners would edit their own copies and then have to merge their changes manually in multi-day meetings. We started looking at Requirements Management tools like DOORs, RequisitePro, Rally, and others. Since the company had a license for IBM RequisitePro, we attempted to use it. However, RequisitePro was very difficult and inflexible. In many ways, it was worse then Excel. So, after some real world user testing, we abandoned it.

The Product Owners continued to add Product Backlog items and last I heard, in 2012, the PBL contained over 3000 items and was virtually impossible to manage. It also represented a massive 10 year inventory of work.

How Agile is a 10-year Product Backlog? Of course, it’s not Agile at all. On average, any new item entering this queue will take 10 years to complete.

Saying “No” Decreases Inventory and Increases Agility

If your Product Backlog is so big and complex that you think you need a tool (beyond cards or Excel) then most likely the problem is your Product Backlog itself.

If the Product Backlog is too big and too complex then the solution in not a tool, the solution is to simplify your Product Backlog.

Agile Manifesto’s first value is individuals and interactions over processes and tools, and this is the key value to make product development successful.

If there are hundreds of software developers building one product, maybe a tool will be valuable. However, my experience is that these tools actually reduce the amount of collaboration and shared understanding between the people defining what is needed and the teams doing the work.

The Three-Month Product Backlog

When I am coaching product management staff (POs, BAs, Directors, etc.) these days, my advice is to keep your Product Backlog to at most three months of work. Yes, only three months (queue catcalls and shouts of “that’s impossible here!!”).

Beyond three months, I coach POs to tell stakeholders that they will come back and consider new items next sprint, but for now they cannot put it into the Product Backlog unless they are going to remove something else.

This shortens conversations with stakeholders greatly, and makes the Product Backlog much easier to manage since it is only three months long. It also has the nice effect of keeping stakeholders engaged when they need to be. If stakeholders can’t get their item in the next three months they may look for alternatives, and that is a good thing.

Saying “no” to stakeholders increases their agility since they can consider alternatives (for example, they may buy a solution) instead of waiting years and becoming very frustrated as they did in the company with the 10-year Product Backlog.

A three-month Product Backlog works very well because it provides product Agility and gets rid of the need for useless complicated tools for huge and hard to manage Product Backlogs.

I am not saying tools cannot provide some value. They can. However, tools often enable bad behaviors that reduce communication and Agility.

Remember, individuals and interactions over processes and tools.

 

 


  • -

Complex Project Failures: How Labels, Hierarchy & Ego Create Disasters in Management

I recently read an article and Facebook post that got under my skin.

Frankly, as an electrical engineer with 27 years experience in software and product development, a former member of APEGA, and owner of one of those “iron rings”, I disagree with almost everything in The Atlantic’s Programmers: Stop Calling Yourselves Engineers.

The article is clearly written from a place of ignorance about software development.

One of my missions as an Agile trainer, coach and industry leader is to debunk the myth that ego and hierarchy leads to success, and to demonstrate that collaboration is critical in our software-driven society.

A Case Study in Truth: Volkswagen Fail vs Toyota Success

The Atlantic article uses an example regarding Volkswagen citing “The Volkswagen diesel-emissions exploit was caused by a software failing, even if it seems to have been engineered, as it were, deliberately.”

This shows the author has little or no understanding of what happened at Volkswagen and failed to do the necessary research to find out. If he did, he would have discovered that managers told the engineers that 230 euro for the “add blue” emissions subsystem was too costly, and ordered them to find another way, without a budget.

Toyota is out-innovating and bringing higher quality than their competitors. Their management philosophy is “go and see.” Quite the opposite of Volkswagen’s management philosophy of “make it so.”

 

In my certified Scrum courses, this is what I refer to as “belief in magic”. Most of the dysfunction described by the author in this article is not because of the lack of detailed planning or intricate documents but rather bad management decisions that employees, engineering ring or not, are forced to comply with.

Look at it this way… with $100+ billions in failures in software development and IT over the last 40 years, will four years of studying math and an engineering certificate fix these problems?

No, it won’t. It’s not the job title or credentials that causes failure. It is the organization that leads failure.

Scrum, Agile, Computer Science, Engineering, and Reducing Risk

Scrum and Agile are becoming increasingly popular, as noted by LinkedIn’s top 10 careers for 2017. The reason is because Scrum and Agile are the most effective risk mitigation strategies we know for software development.

The complexity of large software products dwarfs the complexity of traditional engineering projects like bridges and buildings.

Now, a bridge and all the engineering complexity required to keep it safe is serious and safety is critical. In fact, a Quebec bridge disaster inspired the Ritual of the Calling of the Engineer (written by Rudyard Kipling) and the iron ring. But, in terms of design and engineering, software is far more complex.

Complex engineering infrastructure like transportation systems, the power grid or pipeline networks would be unmanageable without the far more complex software used to manage these systems. (Image: Shanghai Nanpu Bridge)

 

I have worked with brilliant people with advanced degrees in engineering and computer science. I have also worked with brilliant people who came to the world of software development from the fields of music and psychology. I have admired the huge talents of developers whose only education was through learning on their own. In one company I managed the senior product designer had a high school degree. His colleagues thought he was brilliant and so did I.

Bill Gates failed to complete his first year at Harvard. Does that make him any less of a person?

The Fail of Engineering & Software Without Organizational Change

The ideas in the original article were tried over and over for decades and they failed.

Companies like Google, Apple, Uber and Tesla are moving faster as they continually create tomorrow’s products today, while sleepy manufacturers take 4 years to release a new car that is the same as the old car.

I know this because these companies call me. They want to know how to work like Google and Facebook so they can innovate faster AND build quality in. Why should a farmer sit in a combine all day just to point it down a row of grain when it is possible to automate the machine’s navigation?

Smart People Seek to Make an Impact

A friend quit mechanical engineering after he learned that effectively all of the engineering calculations he had to do to design most components at his employer had been done in the 1940s and were published in tables. He went into IT because the work was more interesting to him since it was new and the problems weren’t solved.

One of my clients makes pacemakers and they use Scrum to build the software that resides in the pacemaker. They use Scrum and automated testing to demonstrate to the FDA that with every iteration (1 to 4 weeks) the working system has no bugs or defects.

Most of the failures cited in this article were failure of management to:

  1. understand technology
  2. empathize with the challenges of building and maintaining complex systems
  3. give staff the time to build quality in

Instead we see management treat IT and software development as purely a cost center without a clear connection to return on investment (ROI). This creates a “cheaper is better” mentality that causes huge dysfunction and waste (see my video on the $8 billion spent on the botched healthcare.gov rollout, a website saved by using Agile techniques and engineers from Google).

There are many problems you can’t engineer or code your way out of.

Organizational Change or Bust

Systems thinking and organizational design are potential solutions to fix the issues mentioned in the article. Many of these problems are rooted in managers making decisions about how the work should be done when they themselves are disconnected from how the work gets done. Would you appreciate having a hospital administrator instruct the surgeon on how to perform surgery on you? Probably only if the administrator is also an expert on your procedure.

Peter Senge wrote about systems thinking and organizational design years ago in the Fifth Discipline. There is no excuse to waste months and years and blame entire job functions when talented engineers, software developers, business managers, and others can create and deliver consumable, useful products as a team, every single week under a different organizational approach.


  • -

Agile Hits the Top 10 on LinkedIn

LinkedIn just released an article on the top career positions based on LinkedIn job posting data in the United States. Leadership roles with Agile and Scrum were in 4 of the top 10 roles. How do you think this relates globally or to the Canadian situation, specifically? If you are a Canadian Agile Leader, pop over to our LinkedIn Group to discuss. 

Below are the top Agile roles according to LinkedIn:

5. Product Manager
Median Base Salary: $97,500
Job Openings (YoY Growth): 3,000+ (11%)
Career Advancement Score (out of 10): 8.0
Top Skills: Product Development, Competitive Analysis, Product Launch, Cross-Functional Team Leadership, Marketing Strategy

7. Technical Program Manager
Median Base Salary: $129,000
Job Openings (YoY Growth): 500+ (49%)
Career Advancement Score (out of 10): 8.0
Top Skills: Agile Methodologies, Software Project Management, Software Development Life Cycle, Scrum, Cloud Computing

8. Program Manager
Median Base Salary: $97,400
Job Openings (YoY Growth): 2,300+ (17%)
Career Advancement Score (out of 10): 7.0
Top Skills: Project Management, Project Portfolio Management, Project Delivery, Vendor Management, Business Process Improvement

10. Scrum Master
Median Base Salary: $100,000
Job Openings (YoY Growth): 400+ (104%)
Career Advancement Score (out of 10): 8.0
Top Skills: Agile Methodologies, Software Project Management, Scrum, Requirements Analysis, SQL

Job rankings were based on a weighted score across five areas: salary, career advancement, number of job openings in the U.S., year-over-year growth in job openings, and widespread regional availability. We looked at data from member profiles, job openings and salaries to rank the best jobs for career opportunity. If the scores were tied, we ranked the title with the most open job listings higher.

You’ll find the full LinkedIn report here:
https://blog.linkedin.com/2017/january/20/linkedin-data-reveals-the-most-promising-jobs-of-2017


  • -

Innovel Announces New Certified Scrum Training Courses in Canada

Tags : 

I am really excited to be back Canada with public Scrum certification courses, after years honing our private and public Scrum training in international markets.

Early bird rates are available and registration is now open in Toronto, Calgary, Edmonton, Vancouver and Montreal:

More fun, More value, More Retention

We offer more than the basics of Scrum in our CSM® courses. While we will teach you about the Scrum framework, the roles, and the techniques to plan and implement Scrum in your projects, we also make this very interactive and enjoyable 2-day workshop style class useful with discussion exercises and group-oriented simulations. 

And, our new Certified Scrum Master Plus™ is CSM® with a 3rd day add-on to help with scaling (multi-team development) questions, Scrum Master coaching and facilitation skills, and creating an implementation plan for your first Scrum. Our students often say that the CSM should be a 3-day course to allow more time to absorb and understand the ideas. They asked, we created this highly beneficial third day, exclusively available with Innovel.

Certified Scrum Product Owner® Training by Innovel will show you how to effectively work with a Scrum team to take a product from idea to implementation. While we cover Scrum basics, this course focuses on Agile Product Management, Lean Startup, working with stakeholders, prioritization, reducing risk and maximizing business value.

Contact rdymond@innovel.net if you would like more information about our private or public training courses or to request a group discount code (10% off for groups of 3 more).