Tag Archives: Teams

  • -

How can a CEO make software development teams deliver more features, faster?

Tags : 

I recently provided some free advice on Linkedin about software development. A manager had recently implemented Scrum to improve their development process.

While things are better, the CEO, who doesn’t really care about what methods they use, was not satisfied. He wants more features, faster. In this organization they have a lot of legacy code, so implementing new features is slowed by the complexity of the code base.

The CEO wants a solution that will speed up development. The CEO has proposed taking the best developers from every team and putting them on one team where they will create designs and prototypes of the new features that will be implemented by the teams.

The CEO thinks this approach will speed things up. If we assume the teams in place today are competent, the CEO’s proposed approach could really damage the delivery organization’s effectiveness, morale and really slow things down. I hear this kind of thing regularly, so here is how I think about this problem.

Update: I received feedback from a reader that I should explain why the CEO’s proposal will not work. I skipped this explanation because it will take more time and take away from the point of the article. The situation is similar to a person who doesn’t understand cars trying to fix one. They can spend lots of money replacing car parts and never fix the problem.

Here is my analysis of the risks of the CEO’s proposal. Feel free to skip this specific analysis if you want focus on the solution

In this specific case the solution proposed by the CEO is to take the best developers from the current teams to create a new “super” team. The “super” team’s mandate is to create designs and prototypes for the other teams to implement. So the “super” team won’t actually deliver new features customers can use. Every design decision the “super” team makes now needs to be conveyed to the other teams. This “super team” idea increases communication overhead, slows delivery of new features, takes the most productive developers and stops them from delivering features. The “super team” also breaks the currently functioning teams by removing their best developers, making the teams less productive. The intellectual capacity of the team members is wasted because now they only follow the “super” team’s orders (designs, prototypes, etc). This reduced autonomy reduces intellectual capacity of the organization and decreases morale. The staff on the “super team” are also likely to be frustrated, since they are no longer delivering valuable software features, and the work they enjoy the most will be done by others. The people on the “super team” have little experience working together so they will be slow as they figure out how to work together and become a team. The “super team” will spend most of their time communicating instead of coding. The “super team” will likely suffer from departures as the “best” developers, increasingly frustrated with the lack of programming and increased communication overhead look for other jobs. The CEO thinks his proposal will create a team of heroes that will speed up the process. However the solution actually increases communication overhead, increases length of feedback loops (features working or not), slows down the teams, decreases morale, increases waste and creates frustration. Given the information we have today, that the main problem is a legacy code base that is hard to work with (not staff competency), the “super team” solution does not address the core problem.

The organization has a certain speed at which it can produce new things, and the CEO wants the organization to produce faster. Well, every CEO wants that, so nothing new here. The solution proposed by the CEO will not speed up delivery of features, it will slow down the system. The only way the CEO will get an organization that delivers faster is if he pays very close attention to HOW the company builds products, specifically how work flows starting with a new feature request to completed features in production. One can’t fix a system without first understanding how the system works. By paying attention to how work is done, the CEO and every manager can then lead the organization by asking for regular improvements in the process. There are many thinking tools from Lean, the Theory of Constraints, etc. that can help management and teams find problems and solutions.

Getting features out faster is usually the second thing to worry about. Most software that is built is never used. This has been shown in study after study for more than a decade. The only way the CEO will get more value delivered from the organization is to pay close attention to what is being built and ensuring that only the most valuable and important things are being built. This means really understanding what a customer needs AND what they actually use (vs what they think they want). Lean startup provides lots of practical advice to solve this problem of building the right thing.

Since the biggest fastest improvement is achieved by simply not building crap your customers will rarely or never use, I recommend the CEO and the management team together:

1. Change what you are working on to maximize value

Learn: Watch Agile Product Ownership in a nutshell

Read The Lean Startup by Eric Ries (they will enjoy it, written by a tech executive)

Take a 2 day Certified Scrum Product Owner or Lean Startup course from Robin Dymond Contact Us.

Act: Remove as many features as possible from the product backlog (nice to haves, not needed now, not sure who needs it), and harshly re-prioritize the rest of the features.

For example one management team I worked with used the following prioritization scheme:

    1. 1. We’ll go out of business if we don’t have [Feature]
    1. 2. It will cost us lots of money but we won’t go out of business if we don’t have [Feature]
    1. 3. Everything else
    With this re-prioritization the management team discovered that they could get all the 1 and 50% of the 2 priority features done by the deadline. These priorities cut the delivery time by 50% and ensured that the fraud detection system for a major U.S. bank would not hold up a very large re-platforming program. The rest of the 2 priority features were mitigated with manual processes and delivered after the re-platforming.

Apply and Improve: Implement Lean Startup thinking to product feature discovery, prioritization and product feature validation.

2. Change how you organize work to maximize learning, collaboration, and effectiveness of the organization

Managers and leaders:
Learn: Read and study about Lean, Theory of Constraints (TOC), Scrum Velocity
Take a 2 day Lean and Agile for Managers course on these topics from Robin Dymond Contact Us.
Apply: Value stream mapping and Lean tools, TOC.
Hire a Lean Agile consultant to help management and the organization transition to Agile, Lean and TOC management principles and practices. Innovel consultants specialize in this area. Contact Us.
Improve: Measure your starting baseline, including value stream, bottle necks, information silos and velocity. Incrementally improve the value stream, remove bottlenecks, remove silos, and improve flow.

3. Change how you practice design, coding, and testing to improve quality and speed

Learn: Take hands on training in Agile engineering practices and Agile testing.
Apply: Hire a technical consultant to help teams apply Agile engineering and Agile testing practices in their day to day work. Innovel consultants specialize in this area. Contact Us.
Allow time for new practices to be learned and mastered.
Improve: Measure baselines for unit and functional automated test coverage, and code quality. Invest in improving these metrics over time.

Teams working with Legacy code and using Agile face specific challenges. Team members and managers should:
Learn: Read the PDF Working Effectively With Legacy Code and then read the book Working Effectively with Legacy Code
Read about “Technical Debt.”
Apply: Measure baseline technical debt in your system, long term and short term debt. Develop a strategy for paying down technical debt.
Improve: Implement the technical debt strategy together with teams and management and actively manage technical debt.

Metaphor for management: “Does shoving more paper into a printer make it print faster or make things worse?”

smoking printer

Happy New Year!!

  • -

New ebook, Agile Advice

Tags : 

book coverMy colleague Mishkin Berteig started his Agile Advice blog in 2005 when we were both doing Agile coaching for teams at Capital One. His blog was one of my favorite Agile blogs, he was getting out the lessons we were learning and providing smart succinct advice. In many ways Mishkin’s blog was ahead of its time, offering sage advice to issues and situations that many people had yet to come across. Mishkin has taken his blog content, tuned it up and added additional interesting stories in his new ebook Agile Advice. You can check out the blog for many great ideas, while the ebook is a more convenient format for those looking to improve their coaching and Agile transition knowledge.

  • -

How Healthcare.gov could have saved billions of dollars and been delivered in 1/2 the time.

Tags : 

By September 2014 spending on the 15 state health insurance exchanges and healthcare.gov will climb to over $8 Billion dollars*. This huge expenditure for health insurance shopping sites could have been avoided if the federal and state governments had mandated and followed modern software development practices.


$1 Billon USD. We’ll need eight for healthcare shopping sites.

How did the governments, on something as high profile as healthcare reform, decide to use a risky 40 year old process to manage the delivery of the health insurance exchanges?

Comparisons were made between healthcare.gov and amazon.com, yet the way in which these two websites are developed could not be more different. Healthcare.gov used the phased or waterfall approach with 55 different contractors responsible for different aspects, and no one responsible for delivering finished product. Amazon.com uses Scrum, an Agile approach that emphasizes small cross functional teams who deliver working tested features every 2 weeks.

To understand how a website like healthcare.gov could have been delivered using the Amazon.com approach, I created a short illustrated video. This video demonstrates, in a simple way, how to deliver a site like a health insurance exchange using a fraction of the budget in about half the time. These techniques are very similar to how companies like Spotify, Google, Square, Valve, Salesforce, Amazon and many others manage getting software development done.

Got a few minutes to save billions of dollars on software development?

I hope you like this talk, please subscribe on youtube if you are interested in future videos. If you are looking for in person training for yourself or help for your organization, please contact me:

https://www.innovel.net or http://www.scrumtraining.com

Robin Dymond, CST

*Health and Human Services data

*Report by Jay Angoff on Health Exchange enrollment costs per state

  • -

How Spotify Works. Agility with 1 product and 1200 people

Tags : 

Scaling Agile at Spotify. What True Organizational Agility Can Look Like.

Henrik Kniberg and Spotify released an illustrated video on how Spotify is Scaling Scrum and Agile from a 1 team startup to a 1200 person powerhouse of the online music industry. Spotify is a disruptive force in the music industry, forcing record companies, radio stations, and artists to rethink their business models. Spotify is also an Agile company from the ground up. Spotify got its start using Scrum with one team, so there has been no “Agile Transformation” for the company. Instead the company faced the problem of how to maintain the Agility they had with one team while growing quickly.

The video describes their team structure, the organizational structures that span multiple teams, and the key principles that guide their decision making. I think it is fantastic that Spotify was willing to open the Kimono and show the world how they work, and that Henrik, as their Organizational Coach was able to present it is such a compelling visual way.

This is the cutting edge of organizational agility. For most companies, this kind of organizational model is a fantasy, it is so far removed from their current organization’s structure. If I were a music company executive, I would be scared as hell. Instead, I look forward to continuing to help companies achieve their own improvements for Agility in their own business context.

Part 1 of How Spotify’s Engineering Culture Works

  • -

Mirage Scrum

Tags : 

A recent discussion on the Certified Scrum Trainers list regarding Sprint 0 and what was a product prompted me to write a long reply I have posted here. Mirage Scrum is the kind of Scrum that some people practice, where what is being developed looks like something it is not.

This is a true story describing a project that used what I am calling Mirage Scrum. The Scrummaster on this project was a colleague that I advised.

The VP in charge of a large program to integrate a bank’s online products came under the spell of a Boston Consulting MBA consultant with no dev experience and a user experience fixation. Based on the consultant’s advice, a project was setup to create the “vision” of this project, in this case the User Interface for the integrated product portal. The project team was to design the interface using a tool called iRise, that creates clickable UIs, along with typical graphic design tools.

For 3 months this project team worked in creating this User Interface (UI) using Scrum. They had a consultant Scrummaster, a scrumboard, demos, and 2 week sprints. They would demonstrate progress on the UI in the iRise tool. After 3 months they had finished the UI design in the tool, and shown it to all the executives in the bank, who approved, though many wanted to adjust colors, move things around on the screen etc. Everyone has an opinion in UI.

This UI concept was then given to the development organization. Then the fun began.

The iRise tool claimed to generate all the code needed. Well, what it generated was not usable for much of the site, so development decided on PHP. The UI design made many assumptions about the backend that were wrong, so many UI elements had to be reworked. The UI design did not have the correct security interface. Etc.

The executives who saw the completed UI in iRise asked why, 4 months after the final interface demo, was the portal not done?? Development needed to go faster. Marketing projects had been started to market the online portal based in part on seeing the completed UI in iRise. Investments were being made with ad agencies, printers, TV, media and online.

Yet massive data-warehouses had to be developed to integrate data and abstract the portal away from the many disparate systems. Acquisitions that had completely different systems and environments had to be integrated. A very large amount of development remained. This development needed to be rationalized against the UI concept, and tradeoffs, changes, and revisions made. It took a year to get the first version of the portal launched, and multiple releases to complete all of the features needed by each product.

So did the UI project add value? Yes there was value, the same value as there is in a requirements document in a waterfall project. Except that the UI project, with its demos of clickable UIs, created an impression of “done”. Based on what Managers saw in the demos, decisions were made and investments taken. Stakeholders believed the Mirage the UI team had created using Scrum practices. You can imagine the conversations between IT and marketing for the following 12 months. Many expectations to manage, IT seen as slow and always making excuses, money lost on purchased advertising space option contracts, and ad agencies doing multiple revisions to marketing material based on the changes in the system under development.

As an Agile Coach in the organization I consulted the SM and tried to persuade the consultant early in the program to find another way that would create real software. Instead of a UI based on assumptions. The consultant had lots of political support for his approach. He said the Company had lots of “consumer anthropology” that needed to be done that could not wait for real software. Since arrowheads and pottery shards were in short supply, I think he meant showing the UI to users, perhaps doing some usabilty tests? I am still not quite sure.

Can you create a vision with using scrum practices? Absolutely. Are you implementing waterfall in 2 week sprints? Absolutely.

Mirage Scrum. Using Scrum practices to deliver artifacts that create the mirage of completed software.

  • -

Scrum adoption and comments on Martin Fowler’s Scrum post

Tags : 

Martin Fowler recently posted the blog entry “Flaccid Scrum”. Martin makes some good points on Scrum and its adoption without the corresponding agile engineering practices. The observations from his colleagues are common, as teams that are new to Scrum and Agile techniques are learning a new way of working. Scrum implementations lend themselves to adoption of Agile engineering practices. The messy code problem is not a result of Scrum, it is Scrum that has brought visibility to low quality code. Having to put code into production early and often forces teams to recognize defects that otherwise would remain hidden for months in a waterfall process.

Semantic diffusion – Martin’s term for the observation that definitions become diffused over time is an interesting idea. In doing Agile adoption at a major Financial organization we called this “death by a thousand copies.” Someone would have a practices based definition of what Scrum was and then share it with other people, with no references back to the underlying principles. They would modify practices to suit their environment, and those practices would become the defacto “Scrum” for that group. Why does does this occur? We found it was because people did not understand the basic fundamental principles of “why” certain practices are put in place. In the market we see many “ScrumBut” implementations of Scrum, where the basic principles and practices of Scrum are are known and understood but not followed. This phenomena is not just a Scrum problem, Object Oriented development and adoption of Lean principles in manufacturing (outside of Toyota) have also been poorly implemented at various organizations. Each implementation however poorly done, gave some benefit to the organization, often a short term benefit. For example car manufacturers like GM learned how to lower inventory and remove waste from their manufacturing plants.

The time tested way to deal with semantic diffusion, death by a thousand copies, and poor quality code, is to implement two foundational values: respect for people and continuous improvement. Respect for people in Scrum is articulated in ideas such as self organizing teams, pull, and commitment based planning. In Lean it is exemplified in the authority that any worker can and should “stop the line” to address defects and implement solutions that eliminate the root cause of the defect. There are many other examples of respect for people. At Toyota employees are expected to continually improve the process, and if it eliminates the job they were doing the company will find another place they can continue to make improvements. In August 2008 Toyota closed two truck plants in the US but did not do any layoffs, instead putting 4500 employees into a massive training program. This security empowers people to implement improvements knowing they do not need to “protect” their current job on the assembly line. Compare this to the Financial organization that employs talented software engineers to implement repetitive tedious manual production release processes instead of empowering these people to build standardized automated processes. Those same engineers have no interest nor are they asked to implement these automated systems because it would threaten the existence of their jobs and their manager’s jobs.

Continuous improvement, also called Kaizen by the Japanese, is the daily work of finding and implementing improvements to the process. In software the process is how to go from an idea to working testing software in production. Those improvements should result in ever faster translation of ideas into software with less effort and less cost. In North America we are obsessed with Goals and Objectives. However what happens if our goal is to never be satisfied with: the current process of delivering value, the quality, and the cost? How do you achieve perfection in the delivery of software for your customers? How do you do that in the shortest cycle possible?

Scrum does not tell software developers to use test driven development, continuous integration, pairing, or automated testing. Scrum was created that way on purpose. Once you start using Scrum, implementing these practices should be part of the continuous improvement cycle. Learn Scrum, learn XP, learn Lean, learn Theory of constraints, and most importantly, learn what your customers need and strive to fill those needs using these great ideas.

  • -

Combining Scrum with Kanban for support and enhancement teams.

Tags : 

I often hear: “How I can use Agile on support teams who do defects and small enhancements on multiple platforms?” Support, “business and usual,” defects, and enhancements are ideal for an Agile team. Think about it for a minute: the changes are usually small and independent, they are doable in a short time, and can often be deployed without major architectural or data related changes. This article describes how Scrum was modified to improve a support team’s process.

In the fall of 2005, a production support team of developers, testers, and analysts was setup to support 5 different production systems. The team was responsible for completing customer support requests for defect fixes and small enhancements. Major enhancements were handled by the platform teams. There were 5 different customers that made requests for each system. The team was setup to use Scrum, with Amy Ripley, CSM as Agile Coach and a single Product Owner. The Product Owner worked with the customers to define a single product backlog with priorities for all requests across the 5 systems. While each customer had different needs, many of the systems had interactions, so priorities were easier to determine than if all were disparate systems.

The team was co-located in an Agile team room and started out using standard Scrum with a 3 week iteration length. As the team and the Coach worked together, they realized that Scrum did not account for some of the unique properties of an enhancement and defect support team such as:

  • Customers want quick turn around on fixing defects found in production
  • Defect and enhancement implementation is small piece work compared to building new application features
  • Requests for changes are independent of each other

Managing 5 customer’s expectations lead to pressure for more frequent updates to production. The Coach and the team saw this as a valid concern, and decided to make changes to their Scrum process that would better suit the small piece work and customer needs for faster turn around. The changes included:

  • Weekly releases to production. Given the production support nature of the team they changed their release pattern from once per 3 week iteration to weekly releases.
  • Allowing work to cross iteration boundaries. Some requests would be started later in the iteration but could not be completed by the iteration’s end. Given the weekly releases, this was acceptable, since the customer would not have to wait for a whole iteration to see the item in production.
  • The regular story board was not providing enough clarity as to what was in progress and its state. A more structured Kanban style board would allow the team and stakeholders to more accurately track progress of work items. A Story board was implemented to show the status of a User Story that was in progress. The story would move with its task cards through analysis, dev, test, and release columns on the board. Each the 5 systems had rows for their stories.
  • A team agreement was made to take each work item from beginning to completion before starting a new work item. As could be expected in a large organization, issues frequently came up that would stop progress a work item. When progress was stopped by obstacles outside of the team’s control, then a team member could start on a new work item. These obstacles were escalated to the Coach, the Product Owner and management for resolution.

This kanban style User Story board really helped the Scrum team, Product Owner and stakeholders understand the state of work at any time. The kanban style User Story board also helped reduce work in progress, since once a story was started, team members would not start on another story until it was completed.

The team continued to use the Scrum practices of self organization, the 4 meetings and a 3 week iteration length. The team and stakeholders valued the planning, it helped set expectations for everyone as to what could be completed in the near term. The demo meeting allowed the 5 Customers gain visibility into all the work done by the team. This “see the whole” is a key principle in Lean and with this team it provided a key benefit to maintaining stakeholder equilibrium, as all of these systems served the same department and overall business function. The Scrum principle of self organizing teams was also maintained, as they achieve higher performance and have higher morale than directed teams. Self organization also frees leadership to innovate and create more effective work environments.

Congratulations to Agile Coach Amy Ripley and team for inventing this Kanban style board and process for their Scrum.

“Two strong personalities and too much debate. Need is the mother of invention”
– James Grenning on inventing Planning Poker

  • -

Creating High Performing Teams

Tags : 

It is widely known and accepted that collaboration is quintessentially agile. What isn’t as widely understood is that true teamwork unlocks a level of collaboration that is hard to come by through any other approach. Even less known is that building, sustaining, and supporting high performing teams takes hard work. It takes an investment from each individual on the team, engagement and focus from management, and a supportive culture.

First, let’s look at the business case behind teamwork. Why would you invest in creating great teams.
Productivity/Speed — True teams have the ability to achieve very high levels of productivity. Teams are able to create work patterns, focus, and shared leadership. These dynamics allow teams to move very fast while maintaining high quality. They are able to achieve more with fewer people and enable the organization to change direction and respond to business demand more effectively.
Innovation/Creativity — When teams reach a point where they can use conflict, and collaborative decision making to solve complex problems in unique ways. When you couple this innovative capability with customer collaboration (as Agile aims to do) you are able to deliver a differentiated business result.
Associate Satisfaction — Most of us enjoy having friends/personal connections at work. Teams allow people the ability to create an environment that builds friendships and engagement beyond the work that they do.

Set Teams Up for Success
In our experience there are some very tangible and tactical ways to help teams take the right steps towards high performance early on in their formation.
Outer Product — Teams need to have a clear vision and goal. They need to be able to answer why they are a team and why they need to achieve for the organization. This needs to be clearly articulated and made continuously visible. Have the team establish a mission, print it out, post it in the room, and revisit it on a regular basis.
Inner Product — Establish a clear reason for each person to be part of the team. Each team member needs to be able to answer what they want personally from being a team. Do they want a better work/life balance, to learn new skills, or to earn promotion or good ratiing from their manager? Having team members understand each others motivation for being a team member creates a strong connection to each other.
Celebrate Success — Celebrating success is not a random act of kindness from management like when they hold a happy hour because they sense low morale. Worse yet, it is not rewarding heroism and “death march” behavior. Celebrating success is having teams recognize specific achievements that they laid out as goals for themselves. This could be as small as a round of applause for the compleition of a User Story or as complex as a team outing celebrating the successful implementation of a release. The point is that they should be for the team and tied to specific achievement of goals that the team set for themselves.
Working Agreements — Teams need to collaborate of the creation of a set of agreements or ground rules that they will hold each other accountable for. These can range from working hours to agreements on feedback and communication styles.
Personal Commitment — A key ingredient for effective teams is the personal commitment of each individual to the team. We go as far as asking each individual on the team what they would be willing to do to help the team become a strong team and achieve its goals.