I’ve had this ongoing discussion with a few of my colleagues who say that the term “Agile leader” is an oxymoron — that the ideal organization is a bunch of Scrum Teams and not much else. Even in an ideal world, I disagree, and here’s why in a nutshell: I’ve never seen, and have not even heard of, an organization that was successful in their pursuit of agility who did not have a strong leader guiding the vision for what the organization can become, motivating people to achieve that vision, nurturing the pursuit of that vision, and protecting, when necessary, the people who want that vision from the people who don’t.
The reason for this is simple and is as old as civilization. As Nicolo Machiavelli observed,
How could we organize if we want flow efficiency? Would we reward managers by their span of service instead of control, part 3, stop organizing by function, and move to something that looks like a product-based organization?
My transforming idea for this question was to think about the organization as legacy code. We understand how to refactor legacy code. It takes a while, and then, weeks or months later, we have code that is much more robust and allows us to move faster.
I am sure you have heard that software developers are lazy. They don’t do much most of the time and only actually work a couple of hours over the day.
When you are in an assembly plant, for example, assembling televisions, it’s an issue in that type of work if someone stops doing his task for just a couple of minutes. Those couple of minutes will mean that fewer televisions will be produced and when we convert that to money, it will raise the cost of the product.
Change is inevitable when it comes to project management. That’s why many project managers are electing to use Agile methodologies wherever possible. Agile project management doesn’t just accept changes, it embraces them, making it more than ideal for tracking the delivery of a project.
In this article, we’ll show you how to create new Agile projects and apply Agile views on Microsoft Project.
When I teach any sort of product/project/portfolio management, I ask, “Who believes multitasking works?” Always, at least several managers raise their hands. They believe multitasking works because they multitask all the time. Why? Because the managers have short work-time and long decision-wait time.
If you are a manager, your time for any given decision probably looks like this:
The work-time is short. The manager might have to gather some data and make an initial decision. Too many managers can’t make the final decision — they need to collaborate with others. That means they wait for the next decision state, often a meeting.
My experience is that many managers prepare for those meetings in advance. They gather the data, make their initial decision and then wait for the meeting. The meeting might not take much time. However, if the managers need more data, the managers have to collect more data and wait for the next meeting.
The managers spend less work-time and much more on wait-time.
Contrast that activity with a well-functioning team (Agile or not). That team will spend most of their time working, not waiting. I use swarming as an example because teams don’t have to be Agile to swarm. Here’s a value stream for an Agile team that tends to swarm:
Technical people — especially those who work as part of an Agile team — need time to think and focus. The more they work as a team, the less “wait-for-decision” time they need. They are all right there. They can decide without any waiting time.
When the decision wait-time dwarfs the actual work time, people stop work on this thing and move to that thing: multitasking. Throughput decreases.
When the work-time dwarfs the decision-wait time, people finish one thing and move to another. Their throughput increases.
Is your decision-wait time too long?
Technical teams, regardless of their project approach, need focus time to minimize their decision-wait time. If your decision-wait time is longer than you want, you might not have the people on the team or the information you need.
And, if you’re a manager, you might have the same problem.
Just because managers multitask all the time does not mean multitasking is the best way to finish the work.
A digital transformation is a major change program that helps a company succeed in the digital age. Embracing new technologies like machine learning, microservices, big data, and the Internet of Things (IoT) is part of that change, as is the introduction of Agile practices including cross-functional and self-organizing teams, DevOps, Scrum, and Kanban. Business models also tend to change when companies digitalize their business-customer relationships, pricing models, partner and supplier relationships, cost factors, and other aspects are likely to be affected.
But to take advantage of new and existing digital assets, align them with physical products and services and create a seamless user experience, and increase the overall value created, companies require product professionals—dedicated, qualified product people who look after the digital assets.
For some companies, this means introducing a new department or group, creating new roles, and career plans. That’s often the case in my experience for businesses in finance, media, travel, insurance, and other verticals that traditionally don’t have product management groups, and where product management is not represented at the executive level.
Note that employing people who are called product owners or product managers does not necessarily mean that a product management function exists. I have seen more than one business that called their project managers and team leads “product owners”, but failed to give the individuals true ownership of the products and equip them with the necessary skills to manage them. The changes required to establish a product management group are far from trivial, and they require executive management support, as I discuss in more detail below.
Companies with an existing product management group usually require up-skilling and retraining their product people, as well as adjusting roles and responsibilities and career plans. This helps the individuals embrace an Agile mindset, take advantage of new techniques and tools-think of hypothesis-driven strategy validation, goal-oriented product roadmaps, and user stories-and effectively collaborate with the Agile development teams. Additionally, companies need to consider how the individuals in charge of digital products collaborate with those responsible for the revenue-generating goods and services. While these changes are not as deep as introducing a new product management group, they still need to be carefully managed.
One of my clients called everyone in charge of a feature, product, and portfolio a “product owner” at the start of their digital transformation. Consequently, people were confused and unsure what it meant to play the role, and the organization’s learning and development program wasn’t effective. This example is representative of many companies in my experience: product roles are often applied ineffectively.
As I have argued before, a product owner or product manager should be in charge of a product—an asset that creates value for a group of users and the business. The individual should manage the product for an extended period of time, usually for several life cycle stages, not just a few weeks or months. This creates continuity of purpose, facilitates learning, and reduces wasteful handoffs.
Individuals who own part of a product are not product but feature or component owners in my mind. They have an important job, too, but their responsibilities differ: they are focused on their specific feature or architecture building block rather than trying to increase the value the entire product creates. People who look after a group of products are not product owners either, but portfolio owners or managers.
To get the roles definition right, start by identifying the company’s products. Consider the revenue generating assets as well as the supporting ones. Take, for example, an insurance policy that helps people protect their home, and the digital products that help customers select and buy the right policy. Then align the physical and digital assets to create a consistent user experience, no matter if the policy is bought online or in a branch, for instance.
Finally, ask yourself who should own each product, and how many teams are required to develop the product. You may consequently have to identify additional people with more specialised roles like feature and component owner who support the overall product owner or manager of the larger offerings.
Once you have the right roles in place, take the next step and determine the necessary skills for each role. While there is likely to be some overlap, different roles have different skills profiles. A component owner, for example, typically requires strong technical skills, as the person will have to help specify interfaces and APIs. Strategy and leadership skills are nice-to-have but not mandatory. A portfolio owner, however, requires strong strategy and leadership capabilities including the ability to develop a portfolio strategy and align powerful individuals.
With the desirable skills in place, assess the actual capabilities of the people who will play the different product roles, for example, by using my product management test. Identify gaps and weaknesses that prevent the individuals from doing a great job. Then determine the right learning and development measures. These may include instructor-led in-class and online training, self-study using books, videos, and articles, and coaching sessions provided by senior product people or product coaches.
Take into account people’s learning preferences and constraints to find the most effective measures for each individual. Avoid generic, cookie-cutter approaches. Don’t expect that a single two-day training course will equip people with everything they need to know; it won’t.
Being an effective product person is a demanding job that requires a broad range of skills. It, therefore, takes time for people to grow into a new product role, particularly when they are new to product management. While you can support people’s learning journey, you cannot speed it up at will. Your best bet might, therefore, be to hire external talent in addition to developing current employees.
Introducing a new product management group or adapting an existing one people requires organizational changes. These range from establishing a product culture to empowering the product people, giving the necessary decision-making authority.
Several years ago, I was working with a large insurance company. At the beginning of my first workshop, I asked the attendees to tell me which products they were managing. “What do you mean?” was the answer I received, “We don’t manage products. We do software, not insurance policies.” There was no common understanding that software assets can be regarded as products in their own right and should be managed accordingly. Instead, the organization employed projects that usually changed a number of different digital products. A project lasted typically just three months, and after working on it, the so-called product owner and the dev team members would be assigned to new projects. If this story sounds familiar, then your company should consider changing the way it operates and organize around products-rather than projects.
At another client, the newly-created product management group looked after the tactical aspects of the company’s offerings. But senior management continued to make the portfolio and product strategy decisions. Needless to say, this work split was ineffective and frustrated the product managers who ended up looking after their backlogs rather than being allowed to take charge of their products, innovate, and create more value. Management lacked the understanding that product people must own the strategic product decisions in addition to the tactical ones, and that senior and executive management should guide product people using a business strategy.
If you want to succeed with digital products, you must not only find the right people and help them acquire the right skills. You must also give them the necessary authority. Product owners that are not empowered do not own their products; they are product administrators or project managers in disguise. Additionally, product management must be represented at the executive level, and not hidden inside IT/development or another business unit. This may require hiring an experienced product leader who acts as the head of product and leads the development of an effective product management group.
To make the necessary changes, you usually require executive management support. The executive leading the digital transformation may also sponsor the introduction or strengthening of product management, and explicitly state it as one of the major transformation objectives. Alternatively, the CEO or managing director makes a great sponsor.
Building an effective product management function is never done; it’s an ongoing process. New people join the organization, experienced people leave or move into new job roles; tools and techniques change; new trends emerge. To make things worse, product management is a comparatively young profession, certainly when it comes to digital products, and we lack standards other professions take for granted.
Take the product roadmap, for example. Different people have different ideas of what a roadmap is, and how it should be represented and communicated. We even call the same product roadmap type different names: goal-oriented, theme-, benefit-, and outcome-based roadmap. It is therefore important that you develop and advance product management norms and standards at your company, and agree for instance, if and when you will use a roadmap that works with goals/benefits/outcomes, which template you will employ, and which term you will use. These standards should define how product management is practiced at the company and serve as a blueprint for new product people.
Creating a community of practice or guild is a great way to help product people develop and advance shared practices and to facilitate learning and networking. Nobody can be an expert in all aspects of product management, as it is such a diverse and evolving discipline.
Brown bag lunches, open-space sessions, failure swap-shops, and internal product management conferences are sample measures that help create and sustain a product community. The key is to give people the time and space to interact and learn from each other. The head of product is usually the right person to sponsor and shepherd the community of practice, and help the group evolve their practices.
Additionally, consider developing in-house product coaches and mentors who can teach junior product people and help with community building. These may be some of the senior product people including the head of product, or dedicated coaches who used to be practicing product owners or managers. While you may find that you require external product coaches and trainers to up-skill people when creating a new product management group or when new trends and techniques emerge, you should not depend on them for an extended period of time. Product management is a crucial business function. You, therefore, want to have the right capabilities inside your organization.
Not long ago, we needed to hire a new manager for my Python team in New Relic‘s product organization. As part of the hiring process, candidates interviewed with the engineers on the team. This post is about how I worked to make that manager-interview process as productive as possible.
As an engineer, I’ve never really known what to do in a manager interview. I’ve always just walked in and expected someone else on the team to ask all the questions. Later, I would offer a thumbs up or thumbs down on the candidate, solely based on my “feelings.” I didn’t want to do that this time around. I wanted to help hire the best possible manager for my team. So I developed a plan.
Working with my fellow engineer Allan Feldman, who would be in the interview with me, we created a shared document listing the four things that were most important to us in a manager for our team. Not the things we thought our director would like. Not the things we thought other teams would like. The things that were the most important to us as engineers.
Next, we came up with questions designed to help us assess the candidates in each area.
Coming up with good questions for each area was surprisingly complicated. It was relatively easy to frame questions for the Respect category, for example, but harder to get at the Innovation issue. To make things come out even, we moved some questions around and slightly reworded them until we had at least three questions in each category.
We decided not to be shy and to go ahead and ask some weird and/or challenging questions. We recalled tough situations that had occurred on our team within the past few months (disagreements between team members, awkward interactions with our former manager, etc.). Then we transformed those experiences into questions we hoped would prime the candidates to describe how they would respond in similar situations. The questions included:
Finally, in preparation for the interviews, Allan and I divided the categories between the two of us. We each took separate notes.
After the interviews, Allan and I did not compare notes until we’d each completed our separate evaluations. We gave the candidates one of four ratings for each category:
Notice there is no “Maybe” rating. We decided that a “Maybe” is a “No” when it comes to hiring. If you’re thinking “Maybe” about a candidate, then you really don’t want to hire them.
If you have the time, it can also be helpful to identify a rubric for the answers to each question to help reduce possible bias. This is especially helpful when interviewing a lot of candidates or when the interview process will stretch on for a long period of time. For example, for the question “When a problem arises on the team, how do you decide at what point to step in and address it? “, you might look at responses this way:
In addition to the ratings, we also included any comments that supported our rating. We tried to keep these comments about objective facts and not subjective feelings. Here’s an example of how this might look:
Technical ability – Strong Yes
The candidate has been a Python dev and has used our Python agent! The candidate gave us the feedback that at their last company, they thought they could have used New Relic Insights more.
Finally, we added an overall rating (our final recommendation to the hiring manager, using the same four choices) and sent it off as promptly as possible. Only then did Allan and I discuss our impressions of the candidates.
Both Allan and I were pleasantly surprised by the candidates’ takes on our questions. For example, to our question “Describe a time when you were surprised by the work of one of your reports and how they spent their time. How did you respond?” the candidate immediately replied with the story of how one of their reports went home and created an awesome new feature, and how the candidate helped the developer get recognized for it. I was expecting a response along the lines of, “Well, they went and did this thing and that wasn’t good. So we had a talk.” But instead we got an authentic, positive response. I felt like any developer would want to get recognized like that.
Similarly, when asked, “When a problem arises on the team, how do you decide at what point to step in and address it?”, one candidate first answered the question, and then asked us what arguments we’d had as a team (if any). They suggested that arguments were good and natural things to have. This led to an honest conversation about how our team functions under stress. I felt we really connected at that moment with the candidate in a way I wasn’t expecting.
Best of all, we got great feedback from Tim Krajcar, the hiring manager for this position: “I’m seriously impressed with the depth of process and the quality of notes that you provided on the candidates. Great job. I really appreciate that you took this process very seriously and put that much thought into it.”
Thanks, Tim. Glad we could help!
Special thanks to Tanya Crenshaw for her helpful feedback on the hiring rubric.
This article originally appeared on New Relic’s blog.
Most managers I meet want to do a good job. They want to provide the vision for the people doing the work. They want to provide coaching if people need it. They want to know that people can deliver the outcomes the organization needs and the managers want.
As their organizations move to agile approaches, these managers have problems: their organization (managers above them) wants to measure them by the old rules which demand control. The people doing the work want less control and more servant leadership. The managers feel stuck in that “messy middle.”
Too often, managers feel this tension because the agile approaches challenge the organizational culture. The culture has not yet changed to encourage experiments, team-based collaboration, and team-based risk-taking.
Here are some examples I’ve seen:
There are many more, but that’s enough for now.
It’s time for managers to apply “how little” thinking to their management control.
I first wrote about how little can we do in relation to projects. I discussed “how little” thinking in Manage It! I explained more about “how little” thinking can help create small stories, continuous integration, and a better agile approach for many teams in Create Your Successful Agile Project.
How might managers apply “how little” thinking to their management, especially around issues of control?
The problem I see is that too many managers are so focused on preventing problems, they don’t let the people experiment on their own. The managers “take care of” the people, not realizing how that feels.
Your business requires more agility than we’ve seen at any time since the industrial revolution. The ability to adapt, change and grow is as important as the production of high-quality products and services. As business leaders, we must do more to create organizations that move with our customers, suppliers, markets, and products. But what is the most effective way to guide change that brings the entire organization along on the journey? How can we create an environment that continues to grow and adapt as customer demands, technologies, and stakeholder expectations change?
Regardless of the industry, this method provides a set of guiding principles and tools to change organizational performance in a rapid, real and durable way. From aligning to the organization and customer’s objectives to delivering products faster with higher quality, here’s how to transform your organization to improve what your teams deliver every day.
Agile transformation changes the business in two ways: how we manage and how our teams work. In part 1, I’ll review the common changes in how we manage and the potential impact of each. In part 2, I’ll discuss the changes in how we work, along with the potential impact.
To enable teams to form, function and thrive, we must change how we manage the development and delivery of products and software. These changes make it possible to form teams, align development and operations responsibilities, provide stable funding for them and keep a balance of expertise that makes them effective. Changes in operations management can account for 40% of the value that comes from agile transformation, and likely won’t be successful without them.
Stable, dedicated multi-disciplinary teams that remain working together until an assigned capability backlog is complete have higher performance than teams where members change on a regular basis. Members of the team are experts in product architecture, business operations, scope and solution definition, system design and development, testing, and system operations. This is in contrast to traditional organizations that are formed along boundaries defined by system or professional specialty. During this step, we also help employees find their appropriate role in the new structure, increasing engagement and reducing fear.
IMPACT: Stable, dedicated teams are up to 15% more effective than alternatives. Team members that don’t context switch improve performance by 20% per loaded context.
When capability and operations teams are consolidated, two results emerge: First, teams develop software that is more efficient to use and operate because of increased accountability and information and second, defects that are found are generally resolved more quickly. Systems are more simple to build and operate
IMPACT: Companies with simplified operations grow 30-50% faster than companies that are more complex.
Today’s funding processes are often driven by legacy practices that seek to tie development investment to particular projects. This has two adverse effects: 1) the first project to require a capability must pay for all the development costs associated with it, even when it is shared and 2) teams must be reconstituted each time funding is exhausted, preventing the team from capturing the benefits of stable, persistent teams. In agile environments, funding processes change to provide an allocation of funding sufficient to sustain teams through the budget period, and those costs are allocated to projects over time.
IMPACT: Divided. Advocates argue that front line teams are best able to allocate funding, while critics cite lack of control as an issue.
A key to agile’s efficiency and effectiveness gains comes from having the ability to start work sooner and continue to drain backlogs until they are exhausted or the business decides that further work is no longer necessary. Upgrading capacity and sourcing process is critical for organizations who choose to capture the benefits of completing work quickly and maintaining stable, dedicated teams.
IMPACT: Optimized resource supply chains can improve organization efficiency 6-8% for complex processes like development.
DevOps practices other modern system technologies (containerization, orchestration, configuration management) improve the later stages of software development and deployment by automating the deployment and operation of systems. They also create a shared working relationship between development teams and system operations, improving failure rates and time to restore systems.
IMPACT: DevOps technology implementation can improve development cycle time by up to 33%.
Coordination and alignment with the business for each development team is critical to improve flow and team efficiency. Product owners represent the business, maintain backlogs to assure items are relevant, grouped into like elements and prioritized. They assure software works as intended and that the business is ready to receive new capabilities delivered by the system. They improve efficiency by providing single points of contact, scope clarification, testing support and business readiness management.
IMPACT: Effective performance by the product owner increases team productivity by up to 35%.
Agile transformation is just like any other transformation: when successful, it can pave the way for a very bright future. When it goes bad, it can be difficult to recover from.
Agile transformation can have a tremendous impact — 50-60% cycle reduction, 90% increase in delivered quality and much more predictable delivery. It can only deliver those outcomes if the change is appropriately designed and managed.
Migration to agile is equivalent to changing the engine of IT development while the car is running. It’s possible, but much more effective when someone is alongside to provide expertise, guidance and help interpret interim results.
If you give a developer a verbal warning for surfing social media all day, you are crushing their autonomy. Insisting on core hours of 10am-4pm violates self-organization. Personal development plans are so PRINCE II. Right?
Well, maybe. On the other hand, having someone relatively experienced and influential on your side, to help shape your career and keep you off the annual redundancies list might actually be quite useful.
Here are four case studies of line management observed with real agile teams, some effective and some problematic. Hopefully, this should help you to consider how to make your own HR practices supportive of great software product delivery.
A development team in online retail is doing pretty well. They are well on track to upgrade their eCommerce system to a modern and well-architected system, and they have established a collaborative technical community across the other half-dozen teams that build the site. Life is good for 11 months of the year, but then the annual ritual swings round again that causes the development team to focus on individualism, job titles, and elusive 2% pay rises. This year, two members of the team feel that it is their time for a promotion. They fill in all the right paperwork, their line manager supports their application at the big review meeting; but to no avail. The feedback is:
Standards are very high, and an “associate engineer” needs to demonstrate more industry experience to be promoted to “engineer.”
It’s difficult to feed this back to the people involved; they feel hard done by and I agree with them. The team carries on over the next month or so, but they’ve lost a bit of momentum and in the corner of my eye I can’t help but notice people looking at job websites.
The promotions process in place has the following effects:
Part of the role of a good scrum master is to work with organizations to help them to evaluate the policy choices they have made. It can help to put some numbers on it. Saying, “People are unhappy because they didn’t get promoted” is likely to attract sympathy but little change. Saying, “Our current promotions system is likely to cost the department hundreds of thousands of pounds,” has a better chance of resulting in positive action.
Takeaway: Good HR practice is like good office facilities management — if it’s done well, you don’t even notice it’s happening.
A small, close-knit development team has had stability in their personnel for many years, until a new developer joins from another department. They settle in well and their technical skills quickly establish a mutual respect among the team. However, the new developer is often late, even missing the 10:30 am stand-up at least once a week. After a few months of raised eyebrows and building tension, the developer in question opens up to the team about a long-term sleep condition that they have been managing for many years.
The team and the product owner (who line-manages the team) recognize this as a genuine problem and accommodate the new developer, and the team returns to a state of productivity and collaboration. Occasionally, people working alongside the team question the very visible fact of the developer’s lateness. The team is quick to highlight the much less measurable fact of the developer’s commitment to the team and the quality of their work. It’s good fun to arrive in the morning to find a 2 am code check-in that solves the current technical challenge.
Takeaway: Genuine productivity of useful, business-relevant work is the most important thing. Teams should be held to account, but only for the things that matter.
A major new product line has been initiated within an enterprise-scale organization. All they need now is a couple of development teams to build it. Hiring external developers will help a little, but most of the people will come from within the technology department. This raises questions such as:
Before the skills matrix excel spreadsheet maxes out the engineering manager’s hard drive, we suggest that we help the teams put together a proposal themselves. We give an example of having done this before, helping distributed team re-allocate themselves in order to alleviate time-zone issues. It took a couple of weeks and some bottom-up leadership but it’s usually a lot less difficult than people imagine. However, the response from the engineering manager is swift:
If we allow people to choose their own team, it will be impossible for the QA, UXD, DBA, and development managers to keep track of their staff!
As a result, both new and existing products were slightly compromised through delays, overheads, and sub-optimal allocation of people.
Having competency leads (QA manager, etc.) should have been a great asset, leading the development of good practice and helping to establish shared standards across the department. However, in this case, the competency lead roles became a constraint.
It might be difficult to make changes that affect people’s roles, but it would be negligent to prioritize maintaining an org chart ahead of forming the best possible teams to build a new product.
Takeaway: Leadership positions should make things better, not be a constraint to work within.
A development team working for a large public-sector agency is becoming increasingly frustrated with one of their number. The source of the frustration is a developer who has moved all around the department, and for the last three months has been a member of a Scrum team building an internal research tool. One of the characteristics of Scrum is that it is really obvious when someone isn’t pulling their weight. While the daily scrum is not intended as a reporting session or a way to micromanage the team, when a developer doesn’t complete a single task all sprint then you can’t help but ask why. Efforts by the team, scrum master, and product owner to encourage and support the individual have little impact. Three months later, the individual has been taken through a fair but increasingly formal performance management process, resulting in the termination of their employment. It’s hard work on all involved, but allowing the situation to continue would have been worse.
Takeaway: Leading agile teams is mostly exciting and rewarding, but if difficult decisions are avoided then it undermines the whole effort.
Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your “mythbusters,” Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken
When Scrum is introduced, Development Teams tend to enthusiastically embrace it. Scrum promotes self-organization, autonomous, multidisciplinary teams and acknowledges individual qualities and contributions to a team effort. Who doesn’t want to be part of a Scrum Team? Quite often, however, after the Scrum honeymoon, people start raising issues:
These frustrations drive some Scrum Teams to abandon Scrum altogether. Today, we’re going to bust the idea that Scrum is an enabler of a meeting culture. A culture in which Scrum teams are stuck in too many unproductive meetings that prevent them from creating a valuable product for their customers.
The Scrum Guide describes the five Scrum events (not “meetings”) that create regularity and minimize the need for meetings not defined in Scrum. Every event has a clear purpose and plays an important role in the inspect-and-adapt cycle of Scrum. The events are time-boxed, which means they have a duration.
Let’s address two of the issues behind this myth separately:
The prescribed time-boxes are based on a sprint of 1 month. For shorter Sprints, the event is generally shorter. The time-boxes are:
The activity of refining the Product Backlog requires, on average, 10% of the capacity of the Development Team. Considering these time-boxes, Scrum doesn’t seem a framework that should result in a meeting culture.
For a full-time developer in a 4-week Sprint, the Scrum events take 22.5% of the time:
If we visualize the Scrum events for a 2-week Sprint it doesn’t look too bad right?
Scrum is built on the observation that software development is a very complex endeavour. As we work together, our understanding of both the problem and the solution grows. This requires collaboration between the people that are doing the work. By bringing in our individual perspective, expertise, creativity and wisdom, we have a better chance of making sense of this complex problem we’re trying to solve. Central to this collaboration are conversations, as Tobias Meyer puts it in his book, The People’s Scrum. Conversations about what has been done, what should be done next and whether or not that actually worked.
Scrum provides a minimal set of boundaries (five events, three roles, three artifacts) to have the appropriate conversations at the appropriate time with the appropriate people. It focusses our conversations on what is important at that point in time, as part of the empirical process of Scrum.
Spending time on the Scrum events is incredibly valuable as it helps us plan the work, align our work with the problem that we’re trying to solve and to continuously improve our process through timely reflection. Within the complex domain of software development, this is not a luxury but a necessity.
So where does this myth come from? We think there are a couple of reasons:
The visualisation of the 2-week Sprint with the Scrum events probably isn’t the reality for many Scrum Teams. The Scrum Guide states that the Scrum events should be used to create regularity and to minimize the need for meetings not defined in Scrum.
But Scrum Teams often attend meetings outside of the regular Scrum events. For example: company wide presentations, knowledge sharing sessions, progress updates to management, one-on-ones, action review meetings, governance cadence meetings, idea generations meetings, workshops, problem solving sessions, decision making meetings, information gathering meetings, bilaterals with the team manager, introductions, issue resolution meetings, community of practice meetings, training sessions, etc. Meetings, meetings, meetings and yet more meetings.
This makes our tidy Sprint schedule a bit more convoluted:
Are the Scrum events really the problem here, or does Scrum simply make the existing meeting culture transparent? Are all these other meetings really necessary? Or are they merely the result of non-optimal implementations of Scrum, with people being part of multiple teams, teams that are not really cross-functional (and have lots of dependencies) and Product Owners without actual mandate. This is where the role of the Scrum Master becomes important; help identify those meetings that aren’t necessary, and eliminate them from the schedule. Help the organisation find other ways to organize work that aligns better with Scrum, so that the need for additional meetings can be minimized.
If we decide to spend time on a Scrum event, it should be facilitated in a way that is respectful of that investment. In reality, most Scrum events are facilitated in a way that is quite boring. The Sprint Review is a lengthy presentation of new features, without opportunities for interaction and exploration. The Sprint Planning has the team sitting around a table for a good four hours, listening to the two people that do most of the talking. The Daily Scrum devolves into in-depth discussions between a handful of people, running up to 30 minutes or more. And because no refinement is done during the Sprint, Sprint Planning tends to drag on and on as work is identified and broken down.
Good facilitation requires focus on the purpose of the event and respect for the time-box. What should we have conversations about? How can we have these conversations in ways that are more effective than just sitting around a table, listening to a couple of people? The role of the facilitator is to keep the conversations on-topic, to create a safe atmosphere and to promote open discussion. Without proper preparation and facilitation, the Scrum events will be (and feel like) a waste of time.
For part-time members of Scrum Teams, the Scrum events will obviously consume a larger part of their workweek. This happens when people are part of multiple teams, or do a lot of work outside of their team. Some people possess a scarce skill that is needed by several Scrum Teams — like database administration or a “rockstar” development. If that person has to join every Scrum event, it will certainly feel like a 5-headed meeting monster.
Is Scrum really the problem here? Or is Scrum simply surfacing existing organizational dysfunctions — like the idea that putting people in as many teams as possible is “more efficient” or that organizations depend on individuals with critical skills.
In many organizations, there is a strong implicit belief that “only sitting behind your laptop is work.” For developers, this is akin to saying that “only coding is work.” These beliefs are often reinforced by classifying “laptop work” as billable work, whereas meetings are non-billable. The core assumption here is that we generate value only when sitting behind our laptops, and that we should maximize this time.
The idea that “only sitting behind my laptop is work” is an old-fashioned idea. Product development is not routine work. We frequently need to have conversations about where we stand, to make sense of what is happening and to think about what next step makes sense. These conversations are necessary and valuable. Although it may feel inefficient to spend time with the entire team in a room (“that’s 3 hours with 6 people; 18 hours of non-billable work!”), it will be more effective in the outcomes that it generates. After all, everyone’s creativity, wisdom and expertise was used to arrive at a shared understanding that is carried by all. We don’t have to spend time after the meeting building consensus, bringing members up-to-speed on what was decided or restarting the conversation as members that didn’t attend bring up good points.
What can you do to improve the effectiveness of your Scrum Events? How can you make them more enjoyable? Here are some tips, based on our own experiences:
“Meetings” have the smell of being boring, tedious and energy draining — a group of people sitting around the table waiting for the clock to signal the end of the meeting. Instead, make your Scrum events into something that is fun to do, keeps the energy up and promotes interaction and conversations.
Facilitate the events as workshops rather than meetings. Start with a clear goal and design a series of formats and facilitation techniques that help achieve that goal. Use energizers to keep the energy up and to create a good atmosphere. Allow everyone to be engaged by using a diverge-converge pattern that breaks down large groups into pairs or triplets and have them join up again to share insights. Close the event by asking what stood out for participants; what did they observe? What did they learn? What can be improved to make the event more effective?
For most managers, attending meetings all day long is pretty much their job. They are used to going from one meeting to another. For a developer this is different. Writing software requires incredible focus and concentration. Having many (ad hoc) meetings throughout the day — even if they’re only a minute — breaks concentration and requires a developer to rebuild this focus. This can take 30 minutes or more, even for experienced developers.
Paul Graham wrote an excellent blog post about this problem in “Maker’s Schedule, Manager’s Schedule.” The Scrum events should already minimize the need for meetings not defined in Scrum. The ones that remain should be planned in such a way that they offer the Development Team as much focus as possible and prevent unnecessary task switching.
Liberating Structures are 33 microstructures that allow you to involve everyone in a group — from extroverted to introverted and from leaders to followers. You can use Liberating Structures to spice up your Scrum events. Move away from the stickies and the whiteboards for a moment, and explore these novel facilitation techniques.
The Scrum events offer the opportunity for transparency, inspection and adaptation. These events are time-boxed, such that every event has a maximum duration. Time-boxes create focus and minimize waste. Sticking to the time-box, although the goal of the Scrum event hasn’t been achieved, forces the team to find a solution for the next time. If you don’t respect the time-box, there isn’t a sense of urgency to fix it.
As a Scrum Team, reserve time to properly prepare every Scrum event. Agree upon the agenda, structure and desired outcome. For example: what structure do we want to use for the Daily Scrum? Will you use the “three questions” or discuss the Sprint Backlog as a starting point? Hold each other accountable on the shown behaviour. If someone isn’t prepared, it’s the team’s responsibility to act on it. A nice tool to help the team understand the purpose and expected outcome of the Scrum events is provided by Crisp with the Agile Meeting Cube .
The Scrum events have clear goals:
If the Scrum events are done in a way to achieve these goals, the need for meetings outside of these events should significantly decrease. Progress updates, action review meetings, idea generations meetings, problem solving, decision making, information gathering; this can all be part of the Scrum events and create space in the Scrum Teams agenda.
If the Scrum Team has to attend a different meeting, they should ask themselves:
To allow Development Teams to work with focus and concentration, additional meetings should be aggressively minimized, except for what is necessary to help the team achieve their Sprint Goal. The entire purpose of the Scrum events is to offer a clear cadence, rhythm and focus that prevent unnecessary task switching.
In this blog post, we’ve busted the myth that in Scrum too much time is spent in meetings. We’ve not only described how time-consuming the Scrum events factually are, but also clarified the purpose and importance. After explaining the origins of this myth, we’ve offered some practical tips to prevent or resolve the symptoms.
What do you think about this myth? Do you think in Scrum too much time is spend in meetings? What are your lessons learned?
Over a decade ago now I got my first team lead role. It was a reasonably unexpected promotion when the existing team lead left shortly after I joined. This baptism of fire introduced me to line management, but also made me question my career choice. But it was, in hindsight, the beginning of a new journey: becoming a software craftsman.
With barely 5 years’ experience, I was certainly no senior developer. And yet, here I had been thrust, into a team lead role. With so little experience I made many, many mistakes and was probably a pretty rubbish boss for the three other guys on the team. I tried my best. But the whole process was very draining. But worse, I started to see programming at a more abstract level. In charge of a team, I could see that all we were was a factory for turning requirements into working code. The entire process began to feel like turning a handle: feed the team requirements, some praise and a little coffee, and out comes working code.
In the end, a lot of software ends up being very similar: how many CRUD apps does the world really need? Turns out billions of them. And yet, in conception, they’re not massively exciting. Take a piece of data from the user, shovel it back to the database. Take some data out of the database, show it to the user. All very pedestrian. All very repetitive. In this environment, it’s easy to become disillusioned with the process of building software. A pointless handle turning exercise.
I moved on from this baptism of fire to my first proper management role. Whereas previously I was still writing code, now I was effectively a full-time manager. I was the team’s meeting and bullshit buffer. It took a lot of buffering. There was a lot of bullshit. I think we even once managed a meeting to discuss why productivity was so poor: maybe the vast number of meetings I was required to attend each day? Or could it have been the 300 emails a day that arrived in my inbox?
If I was disillusioned with the process of writing software before, I now became disillusioned with the entire industry. A large company, little more than a creche for adults, continuing forwards more out of momentum than anything else. Plenty of emails and meetings every day to stop you from having to worry too much about any of that pesky work business.
It was then that I opened my eyes and saw there was a community outside. That programmers across the world were meeting up and discussing what we do. The first thing I saw was the agile community — but even back then it already looked like a vast pyramid scheme. But I was encouraged that there was something larger happening than the dysfunctional companies I kept finding myself working for.
Then Sandro Mancuso and I started talking about software craftsmanship. He introduced me to this movement that seemed to be exactly what I thought was missing in the industry. Not the agile money-go-round, but a movement where the focus is on doing the job right; on life-long learning; on taking pride in your work.
Not long afterward, Sandro and I set up the London Software Craftsmanship Community, which quickly snowballed. It seems we weren’t alone in believing that the job can be done well, that the job should be done well. Soon hundreds of developers joined the community.
The first immediate consequence of my involvement in the software craftsmanship community was discovering a new employer: TIM Group. A company that genuinely has a focus on software built well, with pair programming and TDD. A company where you can take pride in a job done well. The most professional software organization I’ve worked in. They’re almost certainly still hiring, so if you’re looking, you should definitely talk to them.
Finally, I’d found the antidote to my disillusionment with how software is often built: the reason I was frustrated is that it was being built badly. That companies often encourage software to be built slapdash and without care, either implicitly or sometimes even explicitly. If building software feels like just turning a handle it’s because you’re not learning anything. If you’re not learning, it’s because you’re not trying to get better at the job. Don’t tell me you’re already perfect at writing software; I don’t believe it.
Through software craftsmanship, I rediscovered my love of programming. My love of a job done well. The fine focus on details that has always interested me. But not just the fine details of the code itself: the fine details of how we build it. The mechanics of TDD done well, of how it should feel. I discovered that as I became more senior not only did I find I had so much more to learn, but now I could also teach others. Not only can I take pride in a job done well, but pride in helping others improve, pride in their job done well.
Any middle manager building a team knows the struggle of improving productivity in the workplace. It’s hard to motivate employees to do their best, get to know their time management skills, and get insights on how to improve time management within the team.Luckily, there are some practical things busy entrepreneurs and team managers can do to not just boost their personal productivity and organization but let their teams thrive together with that. Let’s see how.
Be sure to track your team’s time expenses – and select the right tool for that purpose. Sometimes, tracking time takes too much time, which destroys the very idea of that.
So you’ll need an efficient tool if you want to manage a team of workers more effectively. It can enhance your business in multiple ways: from managing work assignments and tracking time to running reports and analyzing them, so you can spot weak points and amend them.
The best thing about a specialized product is that it allows you to see what everyone is working on, simplify payroll calculation and deliver projects on time. The tool can be adapted to your work process and used to cut business costs.
One aspect of all this could be a bit challenging though: people are often reluctant to adopt new tools. Let’s see how to do it right so you and your team can boost your productivity with less effort.
It’s easy to introduce the new software product, give people some instructions and let them start using it from day one. But that’s not always effective: help with onboarding is often necessary.
To do this right and eliminate the shock of novelty for people in the workplace, do it in small steps. Instruct your employees in detail how they should use the tool. Also, focus on the benefits each team member will see.
Don’t forget to be an active user yourself. Your employees aren’t going to adopt a piece of technology you don’t seem fond of.
Experts say the first step to better time management is knowing exactly where our time is spent. Now you can achieve that and bring your team along on the journey.
If you want to be a step ahead of the competition and grow as a manager, you’ll need to take a step back and see whether your practices are truly effective. That requires reviewing your management techniques, talking to colleagues and workers and getting feedback, and taking notes.
After that, spend a few days outlining your current habits and practices as a manager, brainstorm ideas on what could be changed. Maybe it’s time for a slightly different direction. Or maybe having new people on board or entering a new niche means you have to build new skills or continue your training.
Not just that, but you should take into consideration the management at all levels in the company. They can go through the process, too. This ensures each department is up to date with their project management, culture company, collaboration and incentive programs.
With smart time management techniques, people can start getting done in less time. The same goes for busy entrepreneurs who are responsible for a whole team. You can find ways to manage less when actually achieving the progress you’re after.
What’s the issue with managing too much? It’s that you don’t delegate enough or coach people on your team.
Management itself takes up a big chunk of your time. But what about the desire to inspire your team to get more done, to help employees build new skills with training, to find new talents and get them on board, and to take big decisions?
The only way to start doing all these again is to cut down on management busywork.
One thing that will help you get there is to stop expecting that much from your workers and instead focus on taking responsibility for the project preparation phase.
Multiple studies suggest that remote talent is the future and the reasons for that are many. Remote employees are those who have found the balance between work and personal life and are pretty happy with how they are living.
That’s exactly what you need – happy faces during meetings. Such people are energetic and motivated to do a good job and but disciplined enough at the same time.
If you haven’t already, get more remote workers on your team. This allows you to choose some passionate and hard-working individuals from around the globe instead of being limited by location.
Once you have more of them on your team, and after the training period, you’d be able to delegate whole aspects of the project to them and let them do what they are good at.
This leaves you with more time to concentrate on what matters, such as business growth.
No busy entrepreneur should end up stressed or forget that there’s a team they’re responsible for. Follow the tips above and be a productive manager of employees who knows how to manage their own time.
Some people think that being a Scrum Master is a part-time job and that you can also be a developer during a project or that a Product Owner can share the Scrum Master role as well. Well, the Scrum Guide does not specifically rule this scenario out, but it is not ideal and especially if you are new to Scrum, I don’t recommend it. The simple reason is that the Scrum Master’s role is more than just being a facilitator during the Scrum Events.
Being a developer on its own is a full time job. There are problems to solve, requirements to understand, discussions to be had. Adding on top of that the role of Scrum Master, where the Scrum Master is there to help support the team and shield the team from trouble, just adds more stress and complexity to the situation. It makes it harder to know which to concentrate more on. Even being a developer on another project still takes away from the Scrum Master duties. What happens is that one of the roles wins out. Usually (but not always) it is the development role as deadlines and pressure increases and the Scrum “stuff” gets ignored.
The same goes for sharing the role of a Product Owner, Project Manager or even just being a normal manager. Something goes wrong and you either do both jobs poorly, or one job poorly. Never both jobs well.
The thing is, the role of the Scrum Master is to make sure that the team is continuously improving, to find better ways for the team to communicate and integrate. To clear the way for the team to work and grow. To run interference and remove obstacles and impediments from that objective. They do this by focusing on the team and its needs. They are the advocate of the Scrum Process that keeps the cycle of continuous improvement and when the team deviates and reverts back to their old ways, which they will when new to Agile and Scrum, the Scrum Master’s role is to bring them back. Teams will deviate; it’s human nature to revert back to something you know, especially when you are under pressure, rather than to push forward into the unknown. It’s the Scrum Master’s role to push across the chasm to bring a team to be performance. An inexperienced Scrum Master facing two roles will likely do the same—not always, but is likely.
For a Scrum Master that shares the role of the Product Owner, there becomes a bigger problem. The two roles are in conflict. The Product Owner is trying to get the product completed as quickly and cheaply as possible. The Scrum Master is there for the welfare of the team. Which one wins out? Well, with a new Scrum Master/Product Owner new to the Agile principles and with the mindset of just get things done, then the Product Owner role wins out. You then get a Scrum Master who goes into “Command and Control” mode, trying to push the team to get things done faster. Compromises in quality are made, and in the end everyone has a bad Agile experience. Mind you, you do not have to have a Scrum Master in a dual or even triple role for this to happen, but it is more likely to happen. It can happen and does happen regardless, but that is a talk for another day.
I have made this mistake. I’ve been a developer and a Scrum Master at both the same time, and even though I had every intention to be a good Scrum Master, I made mistakes. Development work took priority. Then again, there were times during the same project where I would focus more on the Scrum Master role, and the development side suffered. The end result though was that neither role was done extremely well.
Every situation is different, and it is possible that a Scrum Master can take on dual or triple roles, but I would expect that to happen with a highly mature agile team. Not one who is just starting out. I also realize that there may not be a choice. There wasn’t in my case. All you can do in this situation is do your best and look out for the welfare of those on the team, not just those of the customer.
Last time I set out some of the things a Product Owner should be doing—or at least considering doing. Even a quick look at that list will tell you the Product Owner is going to be a busy person.
So in this post, I’d like to suggest some things Product Owners should NOT be doing.
Having a former coder in the Product Owner role can be a great boon. Not only do they know how to talk with the technical team and (hopefully) can command their respect, but they can also see how technology can apply.
But to be an effective Product Owner they need to step away from the keyboard and stop writing code.
One: time. Product Owners add value by ensuring that the code which is written addresses the most valuable opportunities with the smallest, most elegant, delightful way possible.
Every minute spent coding is a minute not doing that.
Second: Product Owners need to empathize with the customer, with the business users, they need to eat, sleep, and breath customers.
Being a good coder—let alone someone called an architect—is to empathize with code, the system, the mechanics of how a system works.
Importantly both requirements and code need to be able to come together and discuss what they see and find a way to bring the two (sometimes opposing) views together. It is a lot easier to have that discussion if the two sides are represented by different people.
Asking one person to divide their brain in two and discuss opposing views with themselves is unlikely to bring about the best result and is probably a recipe for confusion and stress.
That’s not to say both sides shouldn’t appreciate the other. I said before, former coders have a great advantage in being a Product Owner. And I want the technical team to meet customers. But I want discussions to be between two (or more) people.
(I might allow an exception here for Minimally Viable Teams but once the team moves beyond the MVT stage the PO should stop coding.)
OK, senior Product Owners should line-manage junior Product Owners, but they certainly should not be line-managing anyone else. They most certainly they should not be line-managing the technical team.
Product Owner authority comes not from a line on an organization chart, or the ability to award (or deny) a pay rise or bonus. Product Owner authority stems from their specialist knowledge of what customers want from a product and what the organization considers valuable.
If the Product Owner cannot demonstrate their specialist knowledge in this way then either they should learn fast or they should consider if they are in the right role.
Product Owners need to trust the technical team and the technical team needs to trust the Product Owner. Authority complicates this relationship because one side is allowed to issue orders when trust is absent and the other side has to obey.
And again, Product Owner simply don’t have the time to line manage anyone.
Being a good line manager requires empathy with employees and time to spend observing and talking to employees, helping them develop themselves, helping them with problems and so on.
Specifically, that means they should not issue “Roadmaps” which list features with delivery dates based on effort estimates. The whole issue of estimation is a minefield; very few teams are in a position to estimate accurately and most humans are atrocious at time estimation anyway. So any plans based on effort estimation are a fantasy anyway. But even putting that to one side…
Issuing such plans commits other people to keep promises. That is just unfair.
Product Owners can create and share scenario plans about how the product —and world—might unfold in the future.
Product Owners can co-create and share capacity plans which show how an organization intends (strategically) to allocate resources. And Product Owners can work with teams in executing against those capacity plans in order to deliver functionality the Product Owner thinks should be delivered by a date the Product Owner thinks is necessary.
In other words: provided a Product Owner is making the promise that they intend to keep themselves (i.e. they have skin in the game), then they might issue some kind of forward plan.
Outbound marketing, e.g. advertising, press releases, public relations and product evangelism, often end up on the Product Owner plate—particularly when the Product Owner is a Product Manager. And in a small company (think early stage start-up) this just needs to be accepted.
However, in a larger organization, or a growing start-up, Product Owners should seek to pass this work to a dedicated Product Marketing specialist as soon as possible. Both roles deserve enough time to do the job properly.
The Marketing Specialist and Product Owner will work closely together—they are, after all, two sides of the same coin, the Marketing coin. The Marketing Specialist handles outbound marketing (telling people about the product) and the Product Owner handles inbound marketing (what do people want from the product?). (Again, in organizations with established Product Management this is usually easier to see.)
As with outbound marketing, Product Owners often get dragged in as pre-sales support to account managers. And again this is more common in small companies and early-stage start-ups.
There are some advantages to playing second fiddle to a salesperson. The Product Owner might get actual customer contact (salespeople too often block Product people from meeting customers). And Product Owners should be exposed to some of the commercial pressures that salespeople—and customers—encounter.
But doing pre-sales is very time-consuming. And being wheeled in to help deliver a sales will distort the Product Owner’s view of the market—just because this customer wants the product in orange doesn’t mean other customers want orange.
And again, pre-sales is more effectively done by specialist staff as soon as the company can afford them.
Want to receive these posts by e-mail? – join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development
Agile software development. Death March projects. And now: Agile software development and Death March projects in the same sentence. Pretty scary, eh?
In his book, Death March (2nd edition, 2003), Edward Yourdon says Death March projects are becoming increasingly common. I hope that wasn’t true circa 2003, as my experience is that Death March projects were the norm throughout the 1980s and most of the 1990s.
I believe one of the driving forces behind the move toward humane workplaces and lightweight methods was the prevalence of Death March projects. Such approaches began to gain traction in the early 1990s, and became popularized after the Agile Manifesto was published in 2001.
A book came out in 1987 to explain how to run Death March projects on purpose. John Boddie’s book, Crunch Mode: Building Effective Systems on a Tight Schedule, explains how to drive a team of software developers to nervous breakdowns, cardiac problems, divorce, burn-out, and suicide as a way to deliver a project on a very tight timeline.
In the 1980s, I worked on many of these projects. I’ve known very good technical professionals who left the field permanently, whose marriages ended, whose health was destroyed, who required psychological treatment, and even one who committed suicide. I myself wasted many years when I could have been living a balanced life, and instead spent day and night pushing myself beyond all reasonable limits to deliver a piece of software whose value to humanity could never compensate for the human cost of producing it. Many thousands of people did the same.
The good news is the Death March is no longer the norm in software development. I’ve met many younger colleagues who don’t relate to the lifestyle of perpetual 90-hour work weeks. Most of them don’t even believe the tales told by their elders, bless their little hearts.
But there’s bad news, too. That “crunch mode” book is popular among managers today. It has a five-star rating on Amazon. Reviewers think it’s great that there’s a way to break every model of sustainable delivery, planning, and estimation, and force people to deliver on an arbitrarily short timeline regardless of the human cost.
You might say a Death March could be justified if the solution’s value to humanity were great enough to offset the human cost of building it in an inhumane way. The case study presented in the book is of a betting application for a casino. It helped casino owners extract money from gambling addicts in the same way as drug dealers extract money from drug addicts. I leave it as an exercise for the reader to judge whether the value to humanity justified the human cost exacted from the development team. Opinions differ, it seems.
So, what happens on these Death March projects, anyway? In my experience, the following things happen:
Now consider some of the key characteristics of Agile software development:
The main difference between an Agile project and a Death March project is sustainability. There’s an emphasis on sustainable pace in Agile methods.
Another difference is the recognition of the value of human beings. Agile methods tend to consider human factors, while the Death March approach treats humans as resources or “things.” It doesn’t matter if someone burns out and quits the field, loses their family, or commits suicide. All that matters is on-time delivery…and it’s one-time delivery, too. What may happen afterward is of no concern to the Death March manager.
There are more similarities than differences between Agile and Death March projects. What does it mean?
I think it means we can consider an Agile project as a Death March project that is stretched out over time. If a 1980s-style project consisted of nine months of meetings followed by a three-month Death March, then an Agile project might consist of six months of slow Death March. We deliver in half the time, with a strong focus on customer-defined value, close alignment with stakeholder needs, effective use of practical methods and techniques, and close collaboration and teamwork.
If people are doing only the things that directly help with delivery during the Death March, then why waste the first nine months in non-value-add activity? Why not just skip straight to the Death March phase, and stretch it out so that it isn’t stressful?
Without the stress, people don’t have to seek medical help, change careers, start new families, or be buried. The team can continue to work on the next project in a sustainable way. The organization doesn’t have to try and re-market itself so that people are willing to work there.
There’s a common mischaracterization of Agile as “going faster.” If all you really want to do is “go faster,” you’re looking for the Death March approach, not the Agile approach. Good luck with that.
Bob Galen is an agile methodologist, practitioner, coach, and with more than 30 years of experience as a software developer, tester, project manager and leader. We recently sat down with Bob to learn more about what separates mature agile testing teams from the rest, and how leaders can best support those teams in order to consistently deliver working software.
Noel: We hear a lot about the requirement of shortened feedback loops, and development, test, and release cycles that deliver continuous feedback. Continuous feedback is certainly a must-have, but what I don’t hear people talk about a lot is how important it is to actually be able to quickly respond to that feedback, and make informed decisions.
How important is being able to do that, and not just collect or note that feedback, but adjust on the fly to make new decisions, pivots, and responses continuously as well?
Bob: I think this is a really important point, Noel. And it’s not simply related to continuous feedback, but also to the continuous improvement cycle. For example, feedback on adjustments that are raised in team, project, or organizational retrospectives. To your point, our lean-age should be towards doing something about our discoveries, in taking action.
It’s one of the reasons I talk about “stop the line” as a mindset.
If we were part of an assembly line that was building Toyota Corollas and we noticed that current cars were being delivered without rear doors, we would pull the cord and stop the line.
Then what would we do?
I would hope that we would fix the cars. In fact, the sooner we stopped the line, the fewer doors we would have to repair (less rework, less time impact).
But are we done? No!
We have to examine root cause in our process and figure out what is creating the issue. Then we need to…fix it! Only then are we done with the event and can start the line again.
This somewhat contrived story focuses on:
I’d like to reframe the question to focus more on continuous improvement, with a preference for fast feedback, fast understanding, and fast adjustments.
Working software is the ultimate goal and measure of, “Are we there yet?” and, “Are we done?” —Bob Galen
Noel: You gave a session at DevOps East that talked about what makes teams agile teams “mature.” What qualities do mature teams have that other teams may not?
Bob: I guess, first of all, they behave like a team. They have shared goals and they share the work in order to get results. So, skills are not an impediment to collaborating and working together. Activities like pairing on work are commonplace.
Mature teams also hold each other accountable. Accountable to quality deliverables, accountable to each other’s commitments, and accountable to delivery results. You can see this in their work, but very clearly in their retrospectives—where hard conversations are surfaced when necessary.
They also have the courage to challenge outward and upward. For example, if they feel leadership isn’t giving them the landscape to succeed, then they’ll push back on distrust, over-commitment of work, and lack of support resources.
They’re in it together. They succeed and fail as a team. In fact, they defend each other. They help each other. And they work hard to maximize their global strengths and minimize their weaknesses.
And finally, they get sh** done. My friend Josh Anderson spoke about his 3-part hiring requirements for high-performance agile teams during his presentation. His criteria are:
Josh was focused on candidates who could exhibit all three characteristics (the intersection in the Venn diagram).
I think that’s another way of effectively thinking about a “mature” or a “high-performance” agile team. But please don’t get stuck on those terms or goals.
I also want the team to have fun together. To discover the joy in doing great work that drives great customer value.
Noel: You mentioned in your session the need for agile leaders—and other leaders—to have “an increased understanding and respect for software testers and to recognize testers as first-class citizens.” How did it get this bad for testers? How did we get to a point where “leaders” might need to be reminded to do that?
Bob: I’ve been involved in software development for nearly 40 years, Noel. And, yes, that number frightens me from a variety of perspectives.
I think testers have had a second-class citizen rap that entire time. Developers have always been perceived as a value center and testers as a commodity and cost center.
I think a big part of it is many technology leaders come from a software developer background, so they more easily understand the value proposition of development. I’ve actually had the opportunity to lead both development and testing organizations over the years. I also sent myself to many classes so that I could understand the profession and craft of software testing more deeply.
Given that, I think I achieved a much more balanced view towards the value of each. Many leaders lack that broader perspective.
In fact, I think they trivialize the notion of testing. For example, in agile contexts, they think it simply surrounds “checking” user story functionality on a sprint-by-sprint basis. But it is SO much more than that. Or, at least it should be. When you minimize it to simple functional checking, it becomes a commodity that anyone can perform. Or, at least that’s the perception.
They also don’t think of the quality practices that testers can drive, which I discuss in question #5, below.
Noel: You also describe the need for leaders to “understand the power of basing decisions off of the objective evidence of working software.” To me, defining “working” is a little like defining “done,” meaning, extremely difficult. How important is it to learn how other stakeholders define “working,” and then, once you know, does everyone need to define it the same way, or is there room for some variation there?
Bob: I don’t think defining “done” should be the focus. I stand by my comment, and what I’m trying to say is that we, as software teams, often work on many things to build our software. Some of those things include:
ALL of which do not directly deliver value to our customers or stakeholders. In other words, they don’t pay us for the above elements. Sure, all of them are necessary to some degree, but they’re not directly in the value stream.
So, I think the point is not the definition of working software, but the delivery of working software. So that we can determine our direction not from documentation or plans or talking, but from the very thing that we’re building to deliver customer value.
It’s tangible. It reflects the value we’re delivering. The customer can touch it, feel it, interact with it, and give us feedback as to whether it meets their needs and solves their problems.
Working software is the ultimate goal and measure of, “Are we there yet?” and, “Are we done?”
Noel: You’ve talked about how in mature agile teams, “testing is not their only quality practice.” I think that would, at least initially, surprise some people. What, outside of testing helps build quality in, and, secondly, does doing whatever that is relieve some of the burden placed on testers?
Bob: Actually, to be clear, testing is not a quality practice. It is a verification process.
Quality practices are different. They focus on pre-verification activity. For example, the “3-Amigos” is a common practice within agile teams. It’s where developers, testers, and the product owner all work together to vet user stories all along their lifecycle. It’s a collaboration metaphor where each perspective weighs-in on the story definition.
Design reviews, code reviews, and pairing are also hallmarks of quality activities within agile teams. As is working with the customer/stakeholder and product owner to ensure we understand the problem we’re trying to solve.
Sometimes folks refer to some of this as “shifting left” in testing. That is, the testers focus on ensuring that we’re building the right thing and building it right, before verifying it.
Think about it. In many ways, testing is too late to catch defects. Even within the tight feedback loops of agile teams, I’d much rather testers spend some of their time in “up front” activities to ensure we’ve got the recipe right before they focus on testing things.
And yes, if we get the shift-left-balance right, then the testing is more of a by-rote or safety net activity. And it loses its typical, repetitive test-fix-test again nature.
Or, that’s the hope when focusing on building quality in vs. testing quality in.
Ever tried to create a new habit by just thinking or talking about it? Nope, us neither. Seems a bit silly, right?
In this blog we delve more deeply into a couple of the critical, specific practices we adopted as a part of our Agile transformation. Why? We learn by doing. We create new habits, new behaviors, and ultimately, a new culture through…that’s right. Practice.
To quickly recap, our first post was an overview of how we’re investing in our people, practices, and technology to move CA toward business agility. In the second post we shared how we’re creating the safety needed for our employees to make the necessary changes. So now it’s time to look at how to develop habits needed in an Agile business and that reinforce an Agile-lean mindset.
Within each of our lines of business, we’re implementing what we call Big Room Planning: a forward-looking working session where a large group of people comes together to align, focus, and decide on a plan for their shared work. Within Big Room Planning, there are two critical practices:
To help give a better visual of what that means in practice, let’s define what we mean by value streams. An operational value stream for a line of business includes the steps taken to provide solutions, goods, or services to customers. It typically includes almost every function in the company or line of business, e.g., marketing, sales, services, legal and procurement.
Within an operational value stream, there are one or more development value streams. Development value streams include the functions needed to develop and deliver products, systems, IT functionality, or other services. Roles within development value streams typically include product management, development, release management, and SaaS or IT operations.
Here’s a simple example: Our line of business is an Agile Management operational value stream. Its goals are to help our customers redefine how work is planned, executed and serviced -to deliver value, more quickly.
Within Agile Management, we have three development value streams – one for Project Portfolio Management product development (CA PPM), one for Agile Software Development (CA Agile Central) and services, and one for CA IT Service Management (CA ITSM) product development.
Now, you have an idea of why we’re adopting these practices, and who is involved in each of these practices, let’s dig a little bit more into the mechanics of the “what and how.”
Quarterly Business Steering is a lean-agile strategy deployment practice where leaders at multiple levels from each function within the operational value stream come together in person to participate in a facilitated, 1-2 day working session. The goal? Evaluate our strategy from multiple perspectives. Raise risks. Evaluate dependencies. Improve the strategy.
Attendees include everyone from marketing, development, sales, services, customer support and operations teams – and even customers!
Of course, this sort of large, critical, expensive event doesn’t just happen. Before every quarterly business steering session, operational value stream leaders define and clearly articulate a proposed updated line of business strategy (usually through a facilitated day of their own).
Along with that, line of business strategies are matched up against corporate-level strategic goals that direct the entire company in strategy grids so we know which strategies the lines of business will be able to support and how… along with which strategies that don’t make sense to support right now, either due to other work being more critical, or just a lack of applicability.
To get a feel for what it might like to participate in the larger quarterly business steering day, let’s take you through a typical agenda.
First, we set context for everyone in the room with in-person updates from the leaders of the marketing, sales, finance etc. This part is critical because people in the room works in different functional groups. This is the part of the day that is most like quarterly business review sessions that most leaders are familiar with. But then we get to the fun parts.
The majority of the day consists of facilitated working sessions, to collaboratively identify where problems and bright spots exist within current business context and proposed strategies. Why is this fun? Well, when was the last time your leaders got to come out of their silos and work on root cause analysis, and creating solutions…together?
We close the day by asking the whole room to provide a confidence vote on the plan: With a quick glance, we can tell if there is alignment or not.
Once our operational value stream leaders are aligned and focused on a strategic direction, we can leverage that information to inform our products direction and work.
Here at CA Technologies, we leverage the Scaled Agile framework (SAFe) and SAFe PI Planning (another form of Big Room Planning) as the cornerstone practice for our development value streams.
There are a ton of great resources on PI Planning available on the Scaled Agile website and in our blogs. Here are three:
Our business units have (almost) all begun practicing these new critical practices, together to create new organizational habits, a new organizational culture. We’re proud of our people and our teams for how every day they get up and practice, together. Tune in next time as we talk about the tools, technology and products we use to support our people in these new practices.
The increasing demand for high-quality database solutions has forced DBAs to embrace more innovative practices. Today, both big and small businesses are leveraging new database technologies to boost operations and get the most out of their IT infrastructure. As a database administrator, you have to keep up with the fast pace of developments in the industry in order to deliver the best services to project clients.
Well, there are many ways of delivering better services to your clients in database administration. As with any project, the methodology used in running the overall flow of tasks will determine how well everything turns out. There are many approaches to project management including extreme programming, test-driven development, and feature-driven development. However, it is Agile project management that is revolutionizing database administration and as a DBA, you need to get more insight on this methodology.
Agile project management methodology entails carrying out work in short development cycles called sprints. As a DBA, the focus will be on continuous improvement in the development of the database processes. This is a value-driven approach which allows a database administrator to deliver high-quality work and high-priority services to the database owner throughout the life of the project. It is a shift away from the former error-prone approaches to database administration which have always led to the poor relationship between DBAs and clients.
A recent Harvard Business Review report lists some of the organizations that are reaping big rewards from Agile methodology including National Public Radio, C.H. Robinson, John Deere, Saab, Mission Bell Winery, and GE. It calls Agile a revolutionary innovation which every business must embrace.
A recent HP Study carried out among developers and IT professionals showed a high concurrence rate in terms of the results parameters expected in Agile management. These include enhancing collaboration in teams (54%), increasing software quality (52%), and increasing customer satisfaction (49%).
To fully appreciate the impact of Agile management for your project, consider the following principles generally applied:
The integration of Agile management into database administration changes many things, especially in terms of what a DBA will be expected to do. An Agile DBA is expected to do the following:
In essence, being an Agile DBA entails a collaborative working style between the developer and the DBA, adoption of new, flexible development tools, the integration of tailored data management techniques which support Agile DBA management, and continuous streamlining and improvement of the DBA process.