The distributed stakeholders in and complexities of my large e-Governance projects regularly led to delays in the agreed schedules. Business problems tended to delay schedules for implementing e-Governance solutions, in particular software development/integration projects.
How was I to overcome these problems? I thought about applying the Scrum framework to my current e-Governance applications development environment. Though I had confidence in my team's attitude as far as adopting Scrum, I wasn't too sure whether the organizational hierarchy (the stakeholders) and management would allow me to make this change to our working style.
While I was thinking about all of this, I had an opportunity to attend Certified ScrumMaster training by Pete Deemer. I got an excellent quotation from that training: "Let's try to do an experiment for one sprint." I was really inspired by this quotation.
So, for one particular project I scheduled a 45-minute meeting with my immediate manager, the team, and the stakeholders (who had respect for my work and who I felt were strong influencers at the organizational level). I explained to them the details of the basic Scrum framework. We discussed a variety of topics, including Scrum basics, Scrum roles and responsibilities, sprint planning meetings and daily stand-ups, and sprint reviews and retrospectives.
Though the attendees understood the Scrum framework very well, they had questions:
How will the new Scrum role will affect my current role?
My answer was: Really, your current role is neither altered nor affected. Only commitment and attitude matter. The objective is to get rid of time delays and work together as a team to get maximum work satisfaction. Let's try to do an experiment for a two-week timebox (sprint) and see how it goes.
Now we're following ISO (or PMI or whatever). Do existing processes and procedures have to be changed or modified if we use Scrum?
My answer was: You don't have to alter or modify any existing processes and procedures. The objective is to follow the processes and procedures better, to deliver the working applications with better quality. Let's try to do an experiment for a two-week timebox (sprint) and see if we can make use of processes like change control management to get better results.
As an end user of the application, do you want me to attend every daily stand-up?
My answer was: No, you don't have to. We'll give you basic functionality (working software) and will show a demo of that working software on the tenth working day (at the sprint review meeting), so you can start using it immediately. Please give us a chance to try to do this experiment for a two-week timebox and let us show you the result.
As an integration tester, what do I do at the start of the sprint?
My answer was: Your work starts from Day One. You need to understand the architecture of the application. You need to understand how the application is developed. You need to provide your valuable input while application development is going on. Moreover, you have to design and develop test strategies/plans and test cases in parallel. And you have to work on automation. You can get help from application developers; they can help you in reviewing test strategies/plans and automation development. Let's try to do an experiment for a two-week sprint and see how you enjoy working with the architect and development team.
Are there any tools available that keep track and help us make sure that we're strictly following Scrum?
My answer was: There are different tools, yes. But I think that we don't have to use any tool. Commitment and attitude are what really matter here. We'll use the daily stand-up meetings, sprint planning meetings, and the retrospective to make things better. As a team, we'll write our tasks on yellow post-its and place them on a wall. As soon as we complete the task, we'll move the item from "Pending" to "Completed." Let's try to do an experiment for a two-week sprint and see if we think any other tools are required.
Aside from answering these questions, there were important and sometimes difficult challenges, namely: building trust, understanding and acknowledging cultural differences, dealing with stakeholder management, and developing teamwork. But I felt there was one solution for me in dealing with these challenges: Let me try myself to do an experiment for one sprint.
And so, at last, we all agreed to experiment with Scrum for one two-week sprint.
I sat with my organization's marketing manager and team for three to four hours to understand the basic requirements. The result of the meeting was the user stories, and the marketing team by that point understood what a user story looked like. Using these user stories, I prepared a product backlog based on priorities and needs from the marketing team. I involved a team member from marketing with the developers, to teach him how to prepare a product backlog.
After that, we had a sprint planning meeting. The attendees were the marketing team member (as he had a clear idea of requirements), me (the facilitator/coach/mentor), the ScrumMaster (a quality-assurance lead) and the team (one architect, two developers, one development tester, two integration testers, one documentation writer). We split the backlog items into tasks that were as small as they could be while still being doable. During sprint planning itself, we had difficulties picking tasks and figuring out who should do which task. Again, we came to an agreement: "Let's keep all our problems aside for two weeks and experiment with working as a Scrum team for the sprint." Some of the development work was taken by the architect — a really good indication that we were committed and wanted to work together throughout the sprint. And in the end, a major development task was agreed upon for completion and delivery at the end of the first sprint.
We started working on tasks. As a team, we met for stand-ups every day for ten minutes at 10 a.m. We discussed what we did yesterday, what we were doing today, and whether there were any impediments. The team began to like these meetings, since they helped us resolve issues more quickly than we'd been able to do before.
The team also started to like the Scrum framework, because they were getting ownership of the work. The team really felt it could work together. Testers began interacting with the architect and developers to understand the technical overview of application. They started writing their own framework for automation. I really liked that; trust between team members was improving so that they were sharing technical and organizational issues and resolving them together, as a team.
Though the first sprint was overestimated, we did deliver the major feature to the end user — who was pleased and started using it right away. I could see the smile on his face. I felt the end user started to trust the team and the delivery model, because he was getting deliverables on committed date.
So I feel that our motto, "Let's try to do an experiment for one sprint," worked. We are on our way to improving our overall work and scheduling.