I was listening to Neil Benson‘s Scrum Dynamics podcast on implementing Dynamics 365 using Scrum on my way to the office this morning. I started to recant my own project experiences over the past several years and the challenges I’ve faced. Neil made some interesting points and I thought it would be nice to augment his content with some stories of personal experiences I’ve had using Scrum on my own projects.
In my earlier days of Dynamics development Scrum wasn’t yet something that was commonly used or considered by customers. Over time that changed, and I not only appreciated the ability to adapt to changing project conditions, but I felt the outcomes of my teams were significantly better than what would have been possible in a waterfall delivery style. There was always a sense of dread to work on a project for months only to find out some features needed to be refactored or rip out something because of some new piece of information we didn’t know previously. As a developer, there’s nothing more disappointing than to see a system go to production only to find out there were significant requirements that were missed, or we eloquently solved the wrong problem. Using Scrum, I also noticed that there seemed to be a more general sense of accomplishment from both myself and my teams since we were able to have a better sense of control over how the code base was evolving. Being able to see features completed and deployed sooner than later also improved the project experience for everyone including business stakeholders.
A compromise for some projects where Scrum is perceived as too radical of a change from waterfall style is an iterative delivery style. This approach can work and provides a more traditional forecasted delivery schedule, but it feels more of a time-boxed waterfall approach. Often, it’s made to look like an Agile approach by using Agile terminology and daily stand up meetings. While it’s better than sending developers to a closed room with Hot Pockets and Red Bull for 12-month with a stack of requirements it still feels like the waterfall mindset. In my opinion it conveys a false notion that we have complete control over everything and we know everything needed to create a successful outcome.
While Scrum is a wonderful delivery style it is, in fact, a framework as opposed to a specific set of explicit instruction on how to deliver a system. As such how project teams practice Scum often ends up a product of how the customer perceives the right and wrong ways to do things. You’ll eventually encounter technical resources new to Scrum or even non-technical business stakeholders who believe they are experts on the subject because they took a class once or achieved a weekend certification. As a matter of practice, you’ll need to navigate and make compromises in how the project will be run dealing with the challenges and perceptions that may not create the most optimal project situations. The following are some of the situations I’ve encountered during projects using the Scrum framework based on some of the talking points in Neil’s podcast.
Deploying Code in Each Sprint
In a perfect world, I wish every project could have working code deployed to a production environment after each sprint. Unfortunately, there are some customers who value visible progress over all else. It can be challenging to have the team working on what can be considered as plumbing tasks to business stakeholders that routinely demand priority of tasks that produce something they can observe. Tasks that fall out of the observable progress category can become hard fought battles of justification. When business stakeholders hold this perspective the work they deem less valuable often end up on the bottom of the list when it comes to prioritization. Mind you this says nothing about the delivery framework but is more of a reflection of how the customer thinks about how software should be built. A project delivery process dictated in this way is subjected to increased challenges over time. Eventually the amount of technical debt tends to build up as the team attempts to please their masters always prioritizing highlight features sacrificing the necessary foundational work needed.
In other scenarios, the customer policies and procedures may make it impossible to create automation through environments requiring elongated manual handoffs to other teams. This is often done using support tickets with explicit documentation that must be completed with extreme accuracy. I say this hypothetically of course because I’m sure no one has ever had to experience such a thing (lol). I worked with a customer once who had an elevation process that literally took almost 30 days to get even a field label change into the production environment. This was due to the complex procedures and approval processes that had to be followed. It’s in these companies you’ll often notice the political battles that happen between IT and the business because of complaints that it takes too long for IT to do anything. As a delivery team operating in this kind of environment, unfortunately, the challenges faced are often very difficult to mitigate as they are a product of organizational dysfunction and Conway’s Law.
As a result of organizational challenges, you may find yourself in situations where you’re literally prohibited to deploy code in an automated fashion. In these cases, you have to make the best of these circumstances and work to automate what you can. Sometimes that can even mean automating the complexity of meeting the company’s procedural process in order to minimize the overhead as much as possible. In my own experience, as a technical lead, I see myself almost as a guardian to protect the team for unnecessary overhead so they can focus on their work. On occasion, I’ve had to invest my own time in building automation as a proactive measure to prevent challenges I know we would face otherwise.
Use of Specialty Sprints
It seems like many customers love the idea of specialty sprints. Neil clearly doesn’t like them and neither do I. In my perspective it feels sloppy and breaks from the spirit of SCRUM in that we normally do one thing, but in these special occasions, we need to do another thing.
One specialty sprint type that says a lot is the concept of the notorious hardening sprint. This is where the team will now at the end of a development cycle work on making the code “really work” that was presented to work in a previous sprint. Nothing screams technical debt like the necessity of a hardening sprint. In my experience, the need for a hardening sprint suggests over prioritization of development speed or visible features at the expense of quality. We all know that it requires a significantly greater effort to refactor poor quality after the fact, but the reality is that there are times we are forced into these kinds of situations. Whenever I’m forced into compromises especially from an architectural perspective, I always go out of my way to make it explicitly clear verbally and in writing both the cost and the benefit to such compromises. I do this because I know full well that at some point, we’re going to have to address the technical debt and stakeholders will often try to act surprised when this debt must be paid off in order to accommodate future development. As a technical lead, I often take on the responsibility of recording and negotiating the management of the team’s technical debt because I can typically make the best arguments on why certain tasks require prioritization over others along with consequences. In my experience this has been the only defensive measure in an attempt to get business stakeholders to own compromise decisions.
Another type of specialty sprint is the deployment sprint. This is where the team takes an entire sprint just to deploy the solution to production. Once again this suggests something has been wrong during the development cycle if we need an entire sprint to deploy the solution. These kinds of sprints are expensive considering the entire team is tied up to accommodate things that should have been worked on previously. If for example, the project has a 3-month development cycle and the team takes a hardening sprint and a deployment sprint before going to production that means 4 months of the year is spent focused on deployment as opposed to making it part of the development cycle itself. To me, this is a huge inefficiency in the development process that is unfortunately sometimes forced upon the team due to the environment.
Stand Up Meetings
I’ve had projects where the business stakeholders had a strong desire to attend team stand up meetings. It was quickly apparent how bad of an idea this is because many stakeholders find it impossible to remain silent. I have a sense of sympathy from their perspective, but at the same time, it’s often disruptive because the standup turns into an entire meeting. On multiple occasions, I’ve found myself and my team standing for over an hour because our standup was highjacked by a business stakeholder. It can be challenging to prevent this when the political environment isn’t open to constructive input. Depending on the political power and perspective of the business stakeholders they may not care about the decorum of how stand up meetings are supposed to be run. This is particularly challenging because what was meant to be a team meeting can end up becoming a daily hour-long meeting to explain or debate with stakeholders the work being done.
In order to mitigate business stakeholder interference, my usual tactic is to suggest that we set up meetings later to discuss topics in more detail. If possible as the team lead, I’ll sit with the developers impacted to understand the topic if necessary and I’ll attend the follow-up meetings to protect the time and stress levels of my team. Sometimes I’m not able to do this and team ends up being pulled into meetings throughout the day which can have a significant impact on productivity.
Another situation that can happen during stand up is you have developers that want to talk in detail about the work they are doing or some cool thing they created in their code. I can admit that I’ve been guilty of this in the past. In this case, the Scrum master is usually the one to make sure we remain focused and keep our time-box meeting commitment such that we can complete the stand up in 15 minutes or less.
Lastly, one of the common mistakes during stand-up meetings is to go too deep into impediment solutions. When a team member brings up an impediment it’s very easy for everyone to jump in with ideas and suggestions that then turn into additional suggestions. Like meetings running over because of business stakeholder interference, the team can get into discussions that aren’t meant to be had during the stand-up meeting. Sometimes these things can be hot topics, so the best thing is to hold a follow-up meeting with only those who need to attend. When stand-up meetings go over time the challenge is it ties up the entire team which often doesn’t require the entire team to be involved and ultimately burns project productivity.
These are just some of the experiences I’ve had over the years with different customers and how they ended up approaching Scrum. I’m a big fan of the framework, but some customers require more work because of the way they chose to implement Scrum. We just have to be ready to deal with the challenges that were going to happen regardless of the delivery framework used.
Scrum Dynamics 18: Successfully implementing Dynamics 365 using Scrum
If you happened to have missed Neil’s podcast you can listen below:
Scrum for Dynamics 365 Course
As a technical lead, I appreciate the contributions of my SCRUM masters and business analysts. Developers like myself are often much more fascinated with what we are doing with the code and it can be easy to not truly appreciate the value of the software development process itself. We prefer to focus on our technical skill sets and being able to write more sophisticated code. I can tell you from experience in addition to writing code your long-term career success also greatly depends on soft skills and your ability to work effectively as part of a team. Understanding how to work as part of a project team using SCRUM is a necessary skill set that we should all expect to need on customer projects.
Neil has taken the time to create the SCRUM framework and apply it to how we delivery Dynamics 365 projects. I encourage you to include the Introduction to SCRUM for Dynamics 365 course as part of your career development strategy. If you haven’t already make sure to check that out.
CRM Audio Podcast Network
As always if you’re wanting to advance your career then you need to stay up to date on the latest and greatest Microsoft Dynamics content. Subscribe to the CRM Audio podcast network as part of your daily routine. My recommendation is to listen when you have down time such as sitting in an airport or have nothing else better to do like when you’re driving to or from the office.
Categories: Project Delivery