From Problem Space to Solution Space: Why Agile Rituals Matter

25 February 2013

Amandeep Bhatia
Renishaw

For last few years, we've been using Agile methods such as Scrum and XP in our projects. As a team, we've gained a lot in terms of productivity, client involvement, frequent feedback, and many more benefits. But one most important change that I've observed in almost all the teams I've worked with is the level of ownership each team member wants to take and how they've started making suggestions even to product owners about possible improvements, as well as thinking in terms of finding solutions as a team.

In my early days of my career, when I was working on a big project in the aerospace industry, my manager in U.S. told us that we were always shooting e-mails to the U.S. team about problems we were facing related to technology and domain. While this was perfectly OK for new team members like us, it would be great, the manager said, if we could also suggest some solutions along with the problem, as this would increase our confidence and understanding and would help the busy team in U.S. I liked the suggestion very much and started using this practice in my projects. It requires a team member facing a problem or situation to step into the shoes of the customer or requirement provider in terms of approaching the problem. I know that it's not always easy to think in such terms, but at least trying can provide a starting point for discussing the problem in a more involving way for both team and customer.

When I started moving to Agile practices, I found that most of the rituals, such as daily stand-up, retrospective meetings, etc., give us a nice platform to carry forward this approach of thinking in terms of solutions and engaging with the customer or distributed teams more efficiently.

I started sharing this practice with my teams and call it "moving from problem space to solution space." Some prerequisites make it more effective:

  • The team should know what the big picture of its project is, and how the team fits into that big picture.
  • There must be an environment of trust and openness in the team, so that team members are willing to speak their minds and take ownership of work they're doing.
  • The team must have access to the product owner and customer, and proper communication channels must be in place.
  • Team members must keep learning about the domain and about technology, in order to provide better solutions.

In my view, Agile practices focus mostly on team-customer engagement, to find out what the customer really wants and provide the team with various mechanisms to discover and clarify requirements early enough to align development with product goals. As teams start to adapt to these rituals in a project, their overall understanding of the project increases — as does the comfort level of everybody involved. Customers can see product increments early on and provide valuable feedback, which gives more confidence to the team so it can start moving into the "solution space."

Some of the ritual meetings that give the team a chance to gain more knowledge and move toward the "solution space" include:

  • Daily stand-up meetings. These gives team members a daily chance to talk about impediments that are stopping them from working efficiently. These impediments could be customer issues or problems that need to be addressed faster to achieve the iteration goals. In empowered teams, individuals can suggest what's hampering their work and how to remove the obstacles.
  • Release planning meetings. These provide the team an opportunity to understand the big picture of the project: why it's getting developed and how the functionality will be delivered. It also gives the team a chance to understand the product owner's and stakeholders' viewpoints, which helps the team form a context for requirements and enables them to ask questions or provide probable solutions in the best interest of the business.
  • Iteration planning meeting. This is the real playground for developers, as they break user stories into tasks and provide time estimates. It's their chance to interact with the product owner and ask questions needed to understand the story fully. This is the most important stage for blocking steps and having discussions between team and customer. This stage prepares the ground for effectively moving to "solution space."
  • Retrospectives. This meeting is the core of Agile meetings and is highly important from my perspective, as it gives a chance for all team members and stakeholders to give feedback on what’s working, what’s not, and any concerns. It gives the best chance to decide on problematic issues and gives the team a formal chance to discuss its viewpoint. Issues discussed and resolved here can help provide more effective solutions, keeping stakeholder preferences in mind.
  • Iteration demo meetings. This meeting is for customers, when they get to see iteration results as working software and see if their requirements are met. In this meeting, the customer provides feedback and discusses problems, if any, to further help the team understand the software. Often customers discover new requirements/behaviors they want for the software, and they may add more stories. This makes this meeting important for the team to get real feedback and appreciation. It gives the team a chance to showcase its problem-solving abilities to the customer.

A software project is a complex development endeavor with ever-changing requirements. During development, the team and customer both face many problems, and effective communication is needed to resolve these problems. As the team works and gains insight into the project, it can use its experience to provide some solutions/suggestions to make product better. I believe in the principle of empowering the team to ask better questions and provide solutions by taking more ownership of its share of the project, and I promote this in my own team. After all, there's nothing more satisfying than realizing the value of one's work and seeing how it fits into the bigger picture.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3 (1 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.