Pair-Agile Coaching: Work smarter in pairs

Marianne Worren, , , , , , , Leave a comment

Six months ago, the team of Agile Coaches at my company decided to experiment with working in pairs. Previously, we had been working in pairs as a way to onboard new team members, inspired by how our developers do pair-programming. We discovered that it wasn’t just the new team members that benefited from working in pairs. The learning went both ways, and we felt stronger and better at agile coaching. Our hypothesis was that we would create more value in the organization working in pairs than alone.

My agile coaching partner became Annette, and together Marianne and Annette became Marionette. Hopefully, our agile coaching pair would become more empowered and less of a puppet than our name implied.

Marionette decided on a goal for the next six months:

To create a work environment that we don’t need a vacation from.

For us this means establishing a healthy balance between reflection and work load, reasonable working hours, autonomy and motivating tasks. Our workday should give us more energy than it takes, and be sustainable over time. We believe that no matter what your role in the organization is, you create more value when you have energy and space to reflect and learn and to focus on what really matters. Work smarter, not harder. It’s a win both personally and for the organization.

One precondition for this experiment is that we are in control of our own priorities and the way we work. We are lucky to have a high degree of trust from the organization, and are more or less self-managed.

How we did it

Marionette kicked off the collaboration by establishing new routines for continuous goal settings and learning. Our most important routines were weekly recurring meetings called Monday commitments and Friday wins, after inspiration from Christina Wodtke’s Radical focus. Other tools and methods we used for building a strong pair were the Wheel of anything, feedback and retrospectives.

We will now take a closer look at our meetings and the Wheel of anything.

Monday commitments and Friday wins

We start every week with a Monday commitments meeting, where we decide on our goals for the week. Planning in weekly intervals helps us split larger missions in to manageable chunks and achievable steps. We also use these sessions to plan our schedule and to reserve time for preparations and follow-ups on our deliveries in our calendars. Based on our experience, if we facilitate a workshop, we use three times as much time as the workshop itself on preparations, plus the same duration as the workshop for follow-up tasks. That’s five hours in total for a one-hour workshop. Estimating and timeboxing all of our known tasks might sound rigid, but it allows us to visualize how much flexibility and slack we actually have in our calendars. As agile coaches, we want to leave some space for unforeseen tasks and opportunities as well.

Every Friday, we revisit our goals in a Friday wins meeting, where we also look at what we learned. Together we mark each goal as completed or fail. The goals we fail at reaching are dead and buried, so we don’t have a growing backlog of tasks we drag along. Next Monday, we start with a clean sheet. We trust that if the failed goals are important enough, they will show up again. This leaves us more mental space to focus on the tasks with the highest impact each week. For more inspiration on why and how to kill your own backlog, I highly recommend Oliver Burkeman’s Four Thousand Weeks: Time Management for Mortals.

Photo by Mike B on Pexels.com

Wheel of anything

Another useful tool for Marionette has been the Wheel of anything. This cake diagram allows us to portion out our capacity in an honest and realistic way. It keeps our capacity limit on 100%, since it’s impossible to expand the circle. If you try to fit in a new priority, something else needs to go. Now and then, we take a look at our own personal wheels to see if we need to change the slices or reprioritize our tasks.

Wheel of anything, to map out how we prioritize our capasity.
A snapshot of Marianne’s Wheel of anything.

Benefits of working in pairs

After six months of investing in stronger relationships and structure, we now experience several benefits, both individually and in how Agile Coaching is done in our organization. To fully utilize these benefits, we have decided to continue for another six months, even if the experiment now has formally ended. Then we plan on switching pairs. We believe that the benefits we see outweigh the cost of investment and the potential downsides and risks. Maybe our next post will be about the flip side of par-agile coaching? For now, we would like to share what we proudly have gained.

Focus

With weekly sessions for goal settings and learning, it becomes easier to have fewer priorities, stay focused and hold each other accountable. We now do more of the high impact tasks, and say no to the less important ones. We also do less multitasking.

Working closely together also calls for more transparency and honesty regarding our capacity. Visualizations and realistic planning gives us the overview and mental picture we need in order to evaluate if we have the capacity to take on a new task.

Quality

One plus one equals more than two. The quality of our work is way better when we challenge and build on each other’s ideas and utilize both of our differences and strengths.

Wellbeing

Working closely together with someone who knows what you’re dealing with, both professionally and private, is of great support. We care about each other on a personal level and lift each other up. Having fun is also an important part of learning and thriving in our role. Laughter boost our creativity and makes us more confident to play and take on reasonable risk.

Robustness

If one of us is absent, or a new opportunity arises, we can split and still deliver on our commitments. We are flexible to grab new opportunities that are in line with our mission.

Did we meet our goal?

Did we meet our goal of creating a work environment that we don’t need a vacation from? Now that Christmas is near, Marionette feel less of a rush to finish our tasks before the holidays. We already are in control and on track with our work, which is more manageable in size and focus. Both of us even plan on clocking in some hours during the holiday, because our work gives us energy. However, we still believe leisure time to be a healthy win also for our day job, since we can seek other hobbies and get new perspectives and inspiration. But our holidays are no longer just a means to recharge and recover before a new sprint at the office. We enter the holidays with energy to spend on our leisure time as well.

What is your experience working in pairs? What role do you have in your organization, and how do you think you could benefit from working in a pair? What preconditions and pitfalls do you see? Feel free to leave your thoughts and feedback in the comments below.

Advertisement
Pair-Agile Coaching: Work smarter in pairs

Lessons Learned From a First Time Design Sprint Facilitator

Marianne Worren, , , , 5 Comments

Last week I co-facilitated a Google Design Sprint for my colleagues, a process for solving big problems and testing new ideas in just one week. We did the Design Sprint version 2.0, which is the 4-day process instead of 5.

The main activities each day of the Design Sprint v2.0

Top 8 key learnings

The problem we were trying to solve was related to risk assessment in the public sector, so I learned a lot about the domain. I also learned a lot about the Design Sprint process.

One of the advantages of facilitating a Design Sprint is that you can get insight into new and exciting problem domains. But keep your focus on facilititating and don’t be tempted to participate.

These learnings are based on only one time as a facilitator (I have previously been a participant). However, I do find it useful to jot down my own key takeaways while they are still fresh from a beginner’s mind. I also think most of these lessons can be valuable when facilitating other processes.

1. Trust the process

If your domain is complicated or complex (as the public sector can be), parts of the sprint (e.g. the map and the story board) can feel hard and frustrating, and you might dubt that you are on the right track. The timeboxed activities and voting activities are designed to help you progress in a meaningful way.

2. Work together alone

Brainstorming doesn’t work. That’s why we let the participants think and be creative alone in silence. We then mix, match and build on each other’s (anonymous) ideas.

3. Block your calendar and turn off your phone

Blocking everyone’s calendar for a week allows for full focus, efficiency and effectiveness. No multitasking, no context switching and no digital devices (exept when building the prototype).

4. Collaborate with a designer

Design thinking, UX and UI competence is crucial, both in a Design Sprint and in product- and service design in general. The designer(s) should participate throughout the entire sprint.

5. Prepare and adjust

Define the challenge and desired deliverables in the beginning and be open for adjustments as new insight is unveiled during the sprint. Chosing the target customer and target event defines the rest of the sprint and is imporatant to get right. If your organization is large or your domain is complicated or complex, do some research, like system mapping, in advance. Try to get an idea on where the root cause or main problems might be. It might also affect who should participate in the sprint.

6. Choose the participants and experts carefully

The end result depends on the group composition. Make sure you have a cross-functional team with a broad mix of skills that represents the different expertices and interests needed to solve the problem. Make sure some of the participants also have ownership and resources to take the result further. You also have to put some effort into who you invite for the Ask the Experts activity on Monday.

7. Facilitating is hard and rewarding

A Design Sprint requires a lot of planning, organizing and preconditions to be met. The facilitator needs to be well prepared and organized around the activities and the schedule, while at the same time keeping energy and mood high throughout the days.

8. Know when design sprint is not the solution

Design Sprint is not the solution to everything.

As with all new and shiny processes, you need to know when a Design Sprint is not the solution.

Walking through the solution sketches.

Questions

These are some of the questions I still have:

  • How and when do you detect whether your solution should be bought or build? How do you avoid making a prototype of a product that already exists in the marked and is not part of your core domain?
  • If the sprint team is cross-functional, autonomous and self-organized, do you need the Decider role? (The Decider is the person making the last call on all decisions.)

Sources

Other than working together with an experienced Design Sprint facilitator, these were my main sources of information and inspiration when preparing for the sprint:

What is your experience with Design Sprints?

Regardless if you have more or less experience with design sprints, I would love to hear from you in the comments.

Lessons Learned From a First Time Design Sprint Facilitator

What does Agile and DDD have in common?

Marianne Worren, , , , 2 Comments

This evening I attended an inspiring meetup The pillars of Domain Driven Design with Marco Heimeshoff. I am quite new to DDD (Domain-driven Design), and Marco Heimeshoff did a great job explaining it.

In short, DDD is about translating business domain language into code, using one obiquitous language to create a bounded context in which to reason about the domain. This creates coherence and reduces risk and complexity. DDD can also create motivation, as it enables autonomy (through bounded context), mastery and purpose.

programmer2
This picture illustrates how to not do DDD. Using DDD, the developer would implement the code using the same words as the user, like sofa  picture and table.

This talk has got me hooked and I am definitely going to learn more about DDD.

However, being an agile enthusiast, I couldn’t help but noticing the similarities between DDD and Agile. You could basically just swap the word DDD with Agile, and it would have made perfect sense.

From just this one talk, I gathered 10 examples where I felt that the topic could just as easily have been about Agile as DDD.

Example 1

What DDD/Agile is not:

  • New
  • Hard
  • Overhead
  • Only for complex domains

Example 2

It’s a dance, not a march (if someone gives you a three steps guide to DDD/Agile, it’s a hoax).

ddd is a dance not a march

Example 3

DDD/Agile gives you the most benefit in the complex and complicated domain, but can also be valuable in the other Cynefin framework domains.

Example 4

Who should learn DDD/Agile? Everyone involved in the software development process.

Example 5

There is a bunch of methods (that consultants will try to sell you), but they are not the core of DDD/Agile. Only use them if they are useful to you in your context. If you find other more suitable methods, please use them instead.

Example 6

DDD/Agile changes everything in the company (like how we are organized, the way we work, roles). DDD/Agile is a mind turner.

Example 7

The more you try to prove that DDD/Agile works, the more it backfires because people will protect their identity (their existing roles).

Example 8

You are not a DDD/Agile person. You are a problem solving person, aiming to add business value.

Example 9

The first rule og DDD/Agile is: You do not talk about DDD/Agile.

If you use branded names, people will get too hung up on the methods and the practicalities, and lose sight of the underlying purpose (and expect it to come in a box with a certificate).

Example 10

The way to implement DDD/Agile is through small controlled experiments.

This is just the examples I had time to scribble down during that one talk. What other similarities can you find? What are the significant differences?

What does Agile and DDD have in common?

Key Considerations When Starting a Community of Practice Inside Your Organization

Marianne Worren, , Leave a comment

Do you want to change how your organization works? Or do you have a burning passion for a specific technology or field of practice you want to share with your colleagues? Establishing a community of practice is a powerful tool to help you connect across silos and spread your ideas far beyond your own formal position and without direct authority.

Communities of practice have many valuable benefits, as Emily Weber points out in Building Successful Communites of Practice:

  • Accelerating professional development
  • Breaking down organisational silos
  • Enabling knowledge sharing
  • Building better practice
  • Helping to hire and retain staff
  • Making people happier

Personally, starting a community inside my organizations has been extremly rewarding and motivating. I’m constatly growing and learning together with wonderful colleagues from all over the organization, whom I didn’t know from before. However, starting a brand new initiative yourself is more challenging than joining an existing, well established community.

Based on my own experience, here are some key lessions I hope will motivate you to start a community inside your own organization.

1. Be open and transparent

We had our first meeting in January 2017 and since then we have had regular meetings one hour every other week. The meetings are open for anyone in the organization. We are currently about 100 members, and about 20-30 people turn up at every meeting.

As people hear about our community through word of mouth, they get curious and want to learn more before they join a meeting. So for them to know more about what we do, I make sure to document our values, purpose, members list and every meeting. We use Confluence, and our page is open for everyone to see and even edit. It takes about 30 minutes to write a short summary after every meeting, and maybe post some pictures. This also makes it possible for other people to add stuff and comment on the discussions, even those who didn’t attend the meeting. We also have an open channel at Slack.

2. Change topics, formats and locations

To grow your community requires courage to try new things, and it can be helpful to look at your community as a social experiment. Our default agenda is to split into groups and do lean coffee, but more often than not, we have workshops, lightening talks, discussions, presentations and other formats that members suggests. Make a survey and ask for feedback.

An eye opener for me was that while some people loved heated discussions with lots of interactions in the open canteen, others were uncomfortable and would much rather listen to presentations in a closed meeting room. Because of the variety of personalities and opinions I realized I would not be able to please everyone. Thus I have to constantly change the meetings to include different people. The same goes for topics. For agile, you have to find the right balance between agile for developers (e.g. continuous delivery and DevOps) and the more “soft” people oriented topics of agile (e.g. collaboration and culture). You can of course choose to pinpoint it down a specific area and smaller group, but since agile transformation requires a change in all parts of the organization, I try to broaden up as much as poossible.

3. Diversity matter – Also in opinions

Diversity in gender, neurodiversity and different social and cultural background has proven to be an important factor in creating innovation and value. The same goes for opinions. The best meetups we have is when someone openly feels safe to raise their concerns or disagree with what is being said.

This may sound weird, but it is important for us that you do not have to agree that agile is a good thing to join our agile community. Respect for different opinions is a crucial part of creating an open learning culture and avoiding groupthink and echo chambers.

The best meetups we have is when someone openly feels safe to raise their concerns or disagree with what is being said.

sailors-all-hands-navy-military.jpg
Avoid groupthink and echo chambers.

4. Ask for help

This is one of the many patterns from “Fearless change” that have helped me both run a community and in introducing changes in the projects I’m in.

When I was prevented from hosting a meeting in the last minutes, I asked one of the attendants if he could host the meeting. He said yes, and it went really well. What’s even more amazing is that after that meeting, there suddenly was a summary of what had been discussed up on our Confluence page. Someone had voluntarily, without being asked, stepped up and taken responsibility. I have also had someone else arrange for a social meeting after work, and after asking the community it only took one minute before someone immediately jumped to the task.

By including others and letting them help you out with arrangements, you not just take work off your own shoulders. You expand your network and attract new people to the community. You also make the network less vulnerable by depending on one single leader.

5. Just do it

I often find that we are limited by our mental boundaries of what we think we have permission to do. If you have a great idea you strongly believe in and want to spread across the organization, just make sure the idea aligned with the business goals and you have management support. If your organization values the creativity and passion in their employees, you probably don’t even need all the formal approval you might think you do. One huge advantage of not having a formal mandate is more freedom to explore and try out new experiments as the community grows and takes shape, and less time on reporting and administration.

team-motivation-teamwork-together-53958
Who or what is stopping you  from making something awesome?

The next steps

Being a network of people, a community is somewhat fluid and organic. It is therefore impossible to say where our community will be in a year from now. A community requires constant attention and nurturing, so planning and prioritizing the next steps can still be a good idea.

These are the next actions I am currently looking forward to take in order to grow our community:

  • Creating a safe to fail environment, where people can openly share failures as well as success stories (we have some examples on agile initiatives that have failed, but it can be a higher bar to share those stories if your company is in the early progress of creating a learning culture)
  • Expanding the leadership beyond myself, so that the community is not dependent on only one leader
  • Expanding beyond our own organization, sharing experience and learning with other companies

 

Key Considerations When Starting a Community of Practice Inside Your Organization

Five Forces Against Agile

Marianne Worren, , , 4 Comments

Let’s say you had to choose a default strategy for developing software:

  • bureaucracy, waterfall development, centralised decision-making and micromanagement?
  • Or a culture of trust, autonomous cross-functional teams, continuous delivery and iterative development?

Seemingly, people in the IT-industry now have come to recognise the latter as a more successful strategy. We know that agile works. Even in the public sector. Then why is the transformation from slow, rigid and expensive processes to a more successful, cost efficient way of generating better value so hard?

Sure, there are obstacles in factors like these:

  • Budgets
  • Contracts
  • Architecture
  • Organization
  • Legacy systems
  • Tools and technologies

These are certainly real barriers for an agile transition. However, they are all tangible, visible and, dare I say it, easier to deal with than the more complex, darker forces lurking in the shadows of the human mind (they are not really dark forces, but a normal part of our human nature and survival strategies).

In this post I suggest five forces I see working against a better way of developing software. All of them might not be relevant in your context and some are stronger or weaker depending on your context. If none of them are familiar, consider yourself lucky.

1. Individuals resist being changed

If you work in a startup or with innovation, you might be familiar with the diffusion of innovations. Only 16% of people are considered Innovators and Early adopters. Humans have a history of surviving by staying with the pack and following the majority, and most people need serious consideration to accept new ideas. For organizations, the adoption to new ideas are even more complex.

change

2. People enjoy power

Agile is about autonomy, learning by doing and letting the team decide how they solve the problem. This requires a large dose of trust, not just inside the team but from management and leaders. Agile does not work very well in a command and control environment.

Unfortunately, people who are used to being in control and exercise micromanagement will naturally find it hard to let go of their control. It requires a shift from Theory X to Theory Y, where not only leaders learn to trust but the team member stop playing the blame game and learn to take responsibility.

3. “We would rather be wrong than uncertain”

Agile are optimized for changing requirements and uncertainty. Humans are optimized for categorizing data and generalizing problem solving. This gives us the warm and fuzzy illusion of control. We are extremely bad at dealing with uncertainty. As Dan North says it: We would rather be wrong than uncertain.

The irony is that agile sceptics often mistake agilists for being daredevils and risk takers, when in fact agile is handeling risk in a much safer way than what carving assumptions into stone is.

One consequence of this is that we are tricking ourself into believing we can predict the future with mental images based on a weak analogies.

The House Analogy

One often used analogy for software development is building houses. This gives us the illusion that we are building something concrete which we should plan in great and accurate details up front, and it will in fact turn out that way. And the bigger the better. It also implies that demolishing the house and starting over is expensive, when in fact, deleting code and starting over is literally done by a keystroke.

The Elephant Analogy

Another analogy we often use is comparing projects to elephants. “How do you eat an elephant? One bit at a time.” This gives us the illusion that we know exactly how the end result is going to turn out, and we can just split the problem into 100% accurate increments and assemble all the pieces perfectly together at the end. When in fact we are trying to grow a new creature that doesn’t exist yet and no one has ever seen before.

43-eating-elephant

 

4. Agile threatens The Establishment

This is an often overlooked consequence of following the agile principles. Delivering value early and frequently has a significant impact on how we are organized and what skills are needed. Our goal is to get real feedback early. “Working software is the primary measure of progress”. Instead of getting written specifications handed over, developers are working face-to-face with business people and user representatives. We are in the complex domain of the Cynefin framework and apply a probe, sense and respond approach. This greatly reduces the need for detailed planning, estimations and comprehensive documentation up front. Consequently, it reduces the need for coordinators, managers and administrators.

mvp
http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

 

It can then seem like a contradiction when we choose to outsource programming, making it harder to collaborate through geographical distances and cultural barriers. At least it generates more work for management. Christin Gorman has an excellent point about this.

5. Agile is small and cheap

Agile is in a sense about keeping it small and simple and eliminating waste. Simplicity and downsizing does not generate the same amount of need for middle managers, coordinators, documentation, meetings and administration. Yes, we are saving costs and that is a positive force for the company paying for the IT related services. But on the other side we are also cutting income for the people making money out of those very activities that does not generate direct value.

Agile generate less income for management consultancies than the waterfall model (unless you are selling agile coaching, courses and certifications). Unfortunately, money is power and this is a strong force I think often is overlooked by somewhat naive techies. Budgeting and economy is not our favourite topic (and economists  on the other side don’t bother with understanding technology either when they outsource core business to India hoping for cost savings).

And let’s be honest. For humans in general, smaller projects are not as impressive on our resume.

“Don’t fight stupid – Make more awesome”

Introducing and sustaining agile can sometimes seem like a dark and long path through frustrating and complex people issues. Introducing change to a business requires great patience and a positive attitude. But it is also necessary to understand the challenges and unfavorable conditions working against you when all your best effort, logic, reasoning and patient are not getting you any closer to your goal. Recognizing the human drivers at play can make them easier to tackle and to know when to stop banging your head against the wall. Maybe you will even find a way to use them to your advantage?

Taking a deeper look at these human forces will also make you realize that all of them are a natural part of our nature and not as evil as they first might appear.

Fortunately, there are lots of techniques for overcoming people issues. Fearless Change (a wonderful read) by Linda Rising and Mary Lynn Manns contains powerful patterns that will make your mission towards change more fun and more efficient.

Besides, being the most adaptive creature on earth, humans have the capability of learning new skills and adopting to change. Bosses are becoming leaders, test managers are becoming an integrated part of development teams and project managers are providing their skills as coaches and scrum masters. And as I have learned from coaching theory and from reading Fearless Change: In order to introduce change, you have to genuinely believe in the hidden abilities and good intentions of people.

Five Forces Against Agile

An agile approach to quality

Marianne Worren, , , , , , , , , Leave a comment

This post is about how the mindset and methodologies of our company affects the way we work with quality requirements. It further suggests a five step approach on how to work with quality requirements in an agile setting.

Since there seems to be a lot of different definitions and understandings about quality, we’ll start with a brief introduction to the terms.

What is quality?

System or software product quality is the “degree to which a software product satisfies stated and implied needs when used under specified conditions”, according to ISO 25010.

Each stakeholder has an interest in software quality. For example, the user wants the system to be safe, responsive and user-friendly, the developer wants good logging and the product owner wants the system to be easy to change in the future (even if they tend to prioritize more functionality over a maintainable solution, but then it is your job as a tech person to explain the business implications of that decision).

Software quality is categorized into eight characteristics by ISO 25010.

product quality 3
The eight product quality characteristics as defined by ISO 25010.

Related to these characteristics we define non-functional requirements, like numbers of requests per second, security level and response time. We often say that non-functional requirements defines how the system is supposed to be, whereas functional requirements defines what the system is supposed to do.

Some people further make a distinction between external quality and internal quality, where the external quality is experiences by the users and the internal quality is experienced by the developers.

requirements
A simplified view of the hierarchy of requirements.

If it’s not functional, then what is it?

“Non-functional requirements” is not a self-explanatory term. Non-functional is often interpreted as not related to functionality or even worse: technical. When you talk about non-functional requirements you will hear things like “I’m a functional tester/architect/[insert title here], so I don’t care about non-functional requirements”.

To save yourself the pain of having to convince everyone that non-functional requirements are important and actually can be related to functionality, talk about quality requirements instead. Everyone cares about quality. Or at least it’s harder to say “I don’t care about the quality of the product we are making”.

Quality benefits all stakeholders

Quality requirements are a means to deliver value to all stakeholders – not just the end-user. This is why you and everyone involved in software development should work with quality requirements early and continuously:

  • The user expects user-friendlier, faster, more secure and reliable systems.
  • A maintainable system speeds up lead time, bug fixing and time to onboard new team members.
  • Early focus on quality needs helps you make better choices when it comes to technology, architecture and design.

The problem with not paying attention to quality occurs when we are heavily invested in an architecture or technology that simply does not support our needs. We risk spending too much effort on the wrong solution and are faced with expensive changes.

How mindset affects quality

The path to quality depends on your company’s mindset. Is your IT company managed like a production factory where one change takes numerous man hours and goes through several handovers between different activity-oriented teams consisting of resources i.e. people? Or do you work in a company where people are trusted, empowered and encouraged to be creative and practise DevOps with continuous deployment? Taking the same plan-driven approach to quality as you would in a large factory to a modern IT environment will most likely slow you down and create more resistance towards quality work than it will do any good.

How is our approach to quality in agile development different from that in a waterfall development?

The waterfall path to quality

For the sake of simplicity, we’ll look at waterfall and agile as two extremities, even though most tech companies probably deals with a mix of the two.

Back in the days when most of the IT industry were doing software development in a control-oriented linear fashion, quality requirements were carefully analyzed and specified up front. They were written down in a separate document and there were dedicated processes for handling quality. In a way, this is a more structured and easier way of working with quality.

  • You dedicate time for gathering all known requirements up front.
  • You write the requirements once and approve the quality requirements early in the process.
  • You get the quality you specify up front ((unless the handovers are causing too much information loss) even if that turned out to be not what you actually needed).

Besides getting what you ask for and not necessarily what you need, the traditional approach to quality encourage exhaustive lists of requirements up-front. One consequence of this is that the development team are put in a brain-off mode, ticking off check-lists with requirements they don’t have any relation to. This might work well if we are building something predictable and concrete (in the “obvious” domain of the Cynefin framework), but not so well when in a creative and more abstract world where most of the requirements are unclear and changing.

The agile path to quality

In an agile and feedback oriented way of creating software we don’t always have the “luxury” of spending days and weeks on making exhaustive lists of requirements in advance or testing every aspect of the product before going live.

Two important distinctions from the waterfall approach:

  • The quality is mostly built-in by iterating over the product based on feedback from real users and from running the software in production over time.
  • The developers need to work closer with a variety of stakeholders in order to understand the requirements.

Agile doesn’t equal good quality

You might think that an iterative approach to system development with continuous delivery and stakeholder collaboration effortlessly leads you towards good quality. Besides, refactoring is a natural part of agile.

Sure, agile development (with an agile mindset – not just the rituals) can help us enhance quality. It can also do the opposite. From my experience, the way we practice agile does not always emphasize quality in architecture and design the same way it emphasize functionality.  There might be different reasons for this:

  • We don’t make time for planning and documenting the design, because it’s hard to predict up front and will be up for change later.
  • We are strongly driven by the amount of functionality we deliver to the end-user, but not the long-term quality as seen from other stakeholders (a natural consequence of the product owner i.e. customer representative prioritizing the backlog).
  • Convincing the product owner we need to improve quality characteristics, like portability and interoperability, can be hard.

Five steps to quality

How do we ensure the right quality characteristics without wasting time on heavy processes, comprehensive documentation and long check-lists that will soon be outdated?

These are my key suggestions on how to work with quality requirements in a more agile way. I also find this approach useful for more non-agile projects.

1. Define a product quality model for your organization

The product quality model defined in ISO 25010 provides a set of useful quality characteristics and sub-characteristics. Adjust the model to fit your organization, and make it well-known among the different stakeholders. Project managers, test experts, testers, developers, UX and UI experts, architects, product owner and everyone who has an interest in the system should be familiar with the model. This will create awareness and help draw attention to delivering on quality, not just time and cost.

2. Prioritize quality characteristics

For each system, bring the necessary stakeholders together and prioritize the relevant characteristics for that system. The ATAM process can be a good technique for making tradeoffs. This is useful for giving everyone a shared view on what is the goal and purpose of the system.

3. Establish quality requirements

Based on the prioritized characteristics, define clear, verifiable requirements with criteria for satisfaction and corresponding measures. This can be done for both

  • the system or company in general and
  • to any specific change or projects.

For the first alternative you can make a general list of mandatory requirements like the ones you are required to follow by law. These are usually predictable and less likely to change over time. Keep the list short, up to date and only enforce it on changes where they are relevant.

Keep the requirements on a reasonable level when it comes to technical details. You don’t want to tell the experts how to do their job or take the responsibility away from the developement team.

4. Treat quality requirements the same way you treat functional requirements

This one is not obvious: When your test manager identify what types of tests that needs to be run, it often doesn’t matter if the requirements are technical, non-technical, functional, non-functional or whatnot. A requirement is a requirement. What matter is the types of tests that needs to be run. You can test quality attributes like security, logging and interoperability with functional testing, combining them with test of functional requirements. Often there is also an overlap between functional and quality requirements, e.g. when it comes to functional suitability.

Separating quality from functionality might be good for drawing attention to quality, but requires an extra effort in administration and defining processes and responsibilities. Architectural work can also be inconsistent when we separate quality from functionality. For the same reason, I do not differentiate between external and internal quality when working with quality requirements (please leave me a comment if you disagree).

Write user stories and make use of the tools and processes already in place. There is no need to invest in a fancy tool for managing quality requirements (maybe for executing the tests, but not for the requirements themselves).

5. Measure, monitor, evaluate and adjust the quality requirements 

As we gain more knowledge about our domain and as the world around us change, the quality requirements also change.  Make use of feedback from the real world to continuously improve the system and the requirements.

Conclusion

Agile is not a get out of jail free card when it comes to planning and documenting. We shouldn’t spend too much time planning, but we shouldn’t make assumptions when it comes to quality needs either. An early, continuous and systematic approach to quality, as defined above, can make your stakeholders more happy, save you from having to rewrite large part of the system later and even increase lead time.

From the 9th principle of The Agile Manifesto: “Continuous attention to technical excellence and good design enhances agility”.

An agile approach to quality

Is DevOps about to make the same mistake as Agile?

Marianne Worren4 Comments

DevOps is in many ways the popular little sister of Agile. She is not a completely new, rebellious generation, like Agile was to his mother Waterfall, but she looks up to her older brother and has a some opinions of her own.

Coming from the same family, DevOps and Agile have similar values and principles. The highest priority of Agile is to satisfy the customer through early and continuous delivery of valuable software. To create valuable software, Agile insists that business people, customers and developers collaborate and work together. DevOps agree, but her main concern is that Agile does not emphasize collaboration throughout the software life cycle as a whole, all the way to production support. She wants to collaborate with IT operations as well.

The highest priority of Agile is to satisfy the customer through early and continuous delivery of valuable software […]. DevOps agree […].

Agile has already lived long enough to see the consequences of his preachings. Agile principles were picked up by well-intentioned people (and inevitably people with economical motivations as well), turning them into methods and rituals that everyone wanted to join in on. But somewhere along the road paved with good intentions, Agile practitioners took a wrong turn, and the frustration towards Agile started growing.

In the history of Agile, we have seen some unfortunate unintended consequences:

  • Projects not producing a single line of documentation because working software is valued more (this has also been said to be the reason for the decline of UML)
  • Projects being rewarded only for delivering value to the end-user on time – not the quality of the product
  • Customers not specifying any requirements up-front because “You are supposed to welcome changing requirements late in development” or “Isn’t ‘agile’ the just another word for ‘flexible’?”
  • Product owners not representative of the end-users prioritizing features and giving feedback on the product alone
  • Scrum teams having worthless daily standups and other Agile rituals that no one really sees the point in
  • Cross-functional Scrum teams where developers are forced to pair-program and rotate all the tasks, turning specialists into miserable, average performers

Ironically, Agile processes and tools became the main focus for many of its followers, even though the first value of Agile is individuals and interactions over processes and tools. Many practitioners also seem to skip the basic understanding of the values and principles, and applied them with no pragmatic sense at all.

Ironically, Agile processes and tools became the main focus for many of its followers, even though the first value of Agile is individuals and interactions over processes and tools.

Agile received many hate mails because of this. Is DevOps in store for the same kind of misuse and harassments?

A common interpretation of DevOps is that the people implementing the software should be the same people running it. This way, developers are accountable for what happens after release as well. This will lead to better quality, as the developers have an interest in making the system less error-prone and easy to maintain. In a context with virtualization, cloud computing, automated tests and quick and easy deployment, this implementation of DevOps can be a great success.

However, if your organization is a large, complex bureaucracy with old infrastructure and legacy systems where the different IT operations require deep, specialized knowledge, firing the entire IT operation department and having the developers take over might not be a great idea. In this case, instead of spreading the knowledge thin across the different domains of expertise, collaboration between experts might be a better approach to DevOps.

DevOps, like Agile, has some potential pitfalls, like turning specialists into mediocre performers. But even if DevOps is about to make the same mistake as Agile, we cannot blame a concept for our failures. We as practitioners need make sure that everyone involved in the process grasp the values and principles behind what we are doing, and remain pragmatic about it. Us humans apparently need to remind ourselves constantly why we are doing what we are doing not to get too carried away.

We as practitioners need make sure that everyone involved in the process grasp the values and principles behind what we are doing, and remain pragmatic about it.

DevOps does not have to make the same mistake as Agile, as long as we as a community take responsibility for our mistakes with Agile and learn from them.

Is DevOps about to make the same mistake as Agile?