In this two-part blog series, Michael will first discuss useful tips for avoiding sprint issues early and secondly, in Part 2, he will talk about how to deal with mid-sprint corrections. So, join Fairway Technologies’ General Manager Michael Krasowski for a few noteworthy sprint insights for managing an IT team.
Whatever Can Go Wrong – Will Go Wrong
Murphy’s Law is a popular saying that states that "things will go wrong in any given situation if you give them a chance," or more commonly, "whatever can go wrong, will go wrong." Whether you are planning your sprint or are in the middle of your sprint, you should expect things to go wrong from time to time. And that is just fine. But, think about all of the possibilities ahead of time and have your alternatives ready for action. In this blog article, I want to talk about things that may or will happen unexpectedly, and ideas and options for how to deal with them.
Before we jump into dealing with “Murphy” in the middle of a crazy sprint, let’s first talk about how we might avoid problems in the first place, thus keeping “Murphy” at arm’s length to start with. In Part 1 of Useful Tips for Sprint Snafus, we will discuss topics on how we can avoid problems early. We will deal with Murphy in Part 2 of this blog series.
Learning Takes Time
Absorbing the totality of Agile and Scrum takes time and the best way to learn is to just do it. So be patient with your team’s learning curve; it will take time. And in fact, with each sprint, you will incrementally iterate into a well-oiled team. Whether your team is agile or not, it takes time for a team to gel and work well together. If you are adding a whole new way of working (when your team might have been working differently for many years), it may take longer than you think to become a high-performance team. Work to teach, coach, and mentor your teammates throughout each sprint. Two key sprint events—reviews and retrospectives—offer a great forum to provide not only your feedback but also to listen to the full team’s feedback and issues as well. Nonetheless, never hesitate to provide just-in-time coaching in 1-on-1 situations. Your experience and knowledge transfer will help your team avoid future problems.
Be prepared for some amount of team conflict. There may even be unsuitable dialogue that you will need to ‘rephrase’ for your team. In other words, conflict may show that real communication is happening. (That’s a good thing.) When I use the word conflict I mean, differences of opinion, some discord, and even some tension in the team. These are not necessarily bad, if managed and monitored.
For your team to be saying what they really think is so important and can be the foundation of productive collaboration. Veiled communication just wastes time: we always want open and honest communication, so it’s best for everyone to leave their egos at the door. Always promote professional behavior and make it clear that respect and trust are paramount for the team’s success. Unprofessional behavior is never tolerated on my watch. Open and honest communication will help root out issues and problems early, and help your team avoid any downstream “Murphy” matters.
Nurturing Your Product Owner
Yes, I know you will be busy managing your dev team, but do not neglect your product owner. They may need some tender loving care. And their role, to me, may be the most important role in the Agile/Scrum world. Let’s face it, they are the customer and you have no requirements or priorities without them.
Now the product owner may say: “I am just too busy – I just don’t have the time.” Without their input, you are stuck. Go meet with them, face to face, and strategize how you can help them. Gathering and aggregating requirements can be challenging, so product owners may not have the business analysis skills or any additional staff to perform that function. In one scenario I was involved with, the IT department provided analysts into the business units to help the product owners gather and document requirements. In fact, the analyst helped the product owner write user stories in a consistent way following a template approach which, in turn, was greatly appreciated by the development team.
The product owner may have limited time to participate in planning. Product owners need to be involved in the project planning, release planning, and sprint planning activities as well as demonstrations. They must be present for the project to be a success. Use your leadership and interpersonal skills to discuss and work with your product owner to better enable success.
The product owner role may by stressful and challenging for the product owner, especially regarding time management, and, say, being new to Agile and Scrum terms and processes. They are still doing their normal job in addition to being the product owner. Be patient and partner with your product owner, be available for any questions, problems, or issues they are having in their role as product owner. Be prepared to offer assistance to the product owner and have your release and sprint planning activities well organized, to save them as much time as possible in the planning meetings.
A key activity of the product owner is to provide demonstration feedback. So take notes—good notes—and provide all the product owners with written feedback that includes ideas and options after the meeting as well. This saves the product owner time; it is very professional and better enables success by clearly documenting the demo’s results.
What’s Your Organizational Culture?
As we know, Agile and Scrum are based on the philosophy of adaptive planning. That’s been Fairway’s model for a while now. We are always making little course corrections as needed with each sprint and release. But, do your customers or the organizations you work with understand this approach? Many do not, or give lip service to it—that is, their commitment is expressed in words but not backed by deeds.
Each organization’s culture is different and varied. What is yours like? Most do not do any form of adaptive planning—Agile, Scrum, lean manufacturing and all the rest that have been around a very long time. Does your company or customers embrace those approaches? Be aware of these organizational circumstances which may affect your agile projects. You may be heads down cranking out sprints but not be aware of the political, cultural, or organizational implications that could and likely will affect your agile activities.
Typically, management wants budgets and schedules up front and early, or they may not even approve your project. I think that is a good thing. Management is doing their job by allocating and managing limited company resources. Also, executives want concrete plans, deliverables, and milestones throughout the project’s lifecycle, so the project manager, technical leader, or the leader of the self-directed team will still need to have the necessary business documents, reports, and status for your collective leadership—that is, the managers and executives who are sponsoring the project.
So, you should not snub your “Agile nose” at your organization’s leadership or your customers if they “just don’t get it.” I have seen this at times from Agile “purists”….and that is very disrespectful. Management is running a company. They have budgets, schedules, milestones, and timelines. So please respect your organization’s culture and methods. You are the one who needs to adapt your actions to match with their needs. Without the business doing business “things,” there wouldn’t be an agile project in the first place.
So how might you relate to management? Well, striving to work within your organization’s culture might mean presenting artifacts to the executives while running an agile project – this is not an easy endeavor for most agile and sprint teams I have observed. The team is focused on delivering working software not statusing upper management. That is why I like, at times, to have a project leader or project manager on the team to provide the communication conduit and necessary project artifacts to management. Thus, allowing the engineering team to do what they do best, write great software.
That is why having a solid product vision, roadmap, and release plans (which are regularly updated) are essential to show your executives just what you are doing. Those artifacts tend to be more understandable to executives. Be sure to include, budgets, schedules, and feature milestones or whatever else management is looking for.
The Bottom Line
You will never be able to avoid all problems with your Agile projects, but by being aware of the topics we discussed, you might be able to mitigate and lessen their impacts. Remember to be patient and allow your team to incrementally learn the Agile way to do things as well as allow time for the team to just get to know each other and support each other. Healthy conflict is a good thing, and if well managed, will bring your team closer together over time. And, without well nurtured and supported product owners, you many never get the project over the goal line. So, allocate regular time to spend with your product owner to not only help gather, vet, and prioritize requirements, but also look at the process by which the product owner conducts their Agile duties. This is where they typically need the most help. Lastly, pay special attention to organizational, cultural, or political dynamics that may be swirling around your projects. To balance this, provide the necessary management-oriented status artifacts to clearly demonstrate that you are “business aware” and executing the project within the necessary schedule, budget, and functional milestone requirements. Reflect for a moment on where your organization is relative to the topics and issues we discussed here. And think about how you might better adapt and relate your agile work in a more effective way. See you in my next blog: Useful Tips for Sprint Snafus: Part 2.
Want to Learn More?
If you want to learn more about developing effective agile sprint plans, please check out one of my Pluralsight courses: Developing Effective Agile Sprint Plans by Michael Krasowski. URL: https://www.pluralsight.com/courses/developing-effective-agile-sprint-plans.
Fairway Technologies Inc.