Have you ever wanted to introduce Scrum or any other agile practice for that matter and find that the organization won't embrace it? Once upon a time I did so I had to ask the question, “Is being agile by applying individual techniques simply enough?”
For a long time I struggled with being an Operations Manager introducing Project Management into a Functional (silo) environment. Originally my core duties were to manage personnel within IT including application development, the help desk, and an infrastructure team.
Many businesses have changed significantly over the past few years with the economy the way it has been. In this case, the number of staff members decreased, current applications and their need for infrastructure remained the same, and the need for new and upgraded applications grew. Simply put, it was a bit chaotic. It is also overlooked that while downsizing there is additional work for the IT staff with security, asset management, and requests from the user community trying to pick up their added duties in their own functional area.
Though the company wanted to “go back to basics” there was an opportunity to introduce agility into this group. Without the business buy-in I won’t claim that they are doing Scrum, but they are now agile while following the Scrum Framework.
Acting as the ScrumMaster I often had to mask some ceremonies with calendar invites and facilitate the meeting according to Scrum so that it appears that the team was working with a Product Owner. Truthfully they were. In each case this person fits the profile of the Product Owner, yet doesn’t claim to have time for an actual process. Since they show up to meetings on their calendar and it appears to them as being my meeting they allow me to facilitate.
Sprint planning meetings become what they are without the title. The Product Owner joins the rest of the team in our open workspace filled with whiteboards marked up as task boards, markers, posters, and index cards with in arms reach no matter where you are. S/He runs through what they and their stakeholders (of course we call them co-workers and customers) need, we turn them into stories, and have them prioritize. After discussions around each of these, work is pulled for the next two weeks and the team is good to go to work.
Meanwhile we have our daily standups and I work to keep the team clear to continue. One more invite to the Product Owner and s/he shows up with their stakeholders to see what the team has created. When that group gives us feedback and leaves we wrap up with a retrospective and start again. After a few iterations of this the team was solid and department heads were happy to once again be getting what they were looking for.
Now that you have results, do they now want to embrace this? In this companies case no, but as a Scrum Professional I was able to use agile techniques to create efficiency so yes, sometimes it’s enough.
Of course nothing had been upgraded in the past few years and standardization did not exist so my understaffed help desk and infrastructure team were stressed out and overworked. From closing facilities to bandaging computers, servers, and network failures the problems were constant. Ad Hoc requests were coming in and they were simply expected to change gears multiple times in a day.
Since this organization still insisted on being Functional I used that to suggest how our functional area would work going forward. My newly formed team had picked up some of the Scrum Framework from being around it and I brought them up to speed on the particulars. Remember that room with all of the whiteboards, etc…? Well we used one to create a Kanban board and apply Scrum techniques to it.
The team met and starting writing down everything they had been tasked with except for everyday work and trouble tickets. All of this work went up on the board for anyone that wanted to walk in to see.
We assigned complexity to each and since it was our first run out we estimated our capacity for the first Sprint. Using the Director of our functional area as a Product Owner for the business we had him prioritize what needed to be done until there was no more room to add complexity. In this case the team committed to an amount of work and not necessarily the work itself. As the Ad Hoc requests came in the Director maintained the ability to blow up work in progress by making it higher priority even while in the middle of a sprint, but he must then remove an equal or greater amount of complexity points and he answered to the business as to why that product will not be delivered until the next sprint.
This accomplished multiple things. First, it accomplished the original goal which was to make the work visible so that each individual in the business could see that they are not the only ones asking for things from this small team. Second, it relieved the team of the stress from being over their head and improved the quality of their work. Third, it aided in cross training and identifying training opportunities, by allowing them to pull the work rather than being assigned tasks repeatedly.
The Ad Hoc requests continued to come, the requests for an increase in head-count continued to be ignored, and everyone still thinks their need is the company’s highest priority. The difference is that it is no longer on the shoulders of the team. Once again, “being agile” greatly increased efficiency amongst other things while not actually “doing Scrum”.
