Introduction
Throughout the interview process at Graebel I positioned my engineering mindset with agile development methodologies rather than the traditional waterfall mindset. Specifically I was a fan of scrum as I believed the practice was best suited to be applied to the full workload of a corporate enterprise IT department. My long-term plan was to take the scrum approach, apply it not only to new software development but also to support, maintenance and application enhancement development activities. Yet before I could achieve that mission I needed a pilot project where scrum could be applied and to serve as the catalyst for change within my newly acquired development team. We embarked upon that pilot project at the end of 2005 and what follows is a quick description of several aspects of our initial scrum implementation.
Team space
We took down cube walls within a section of cubes to create a six person bullpen. We relocated most of the members of the team into this bullpen to better facilitate face-to-face communication and collaboration.
Note: We were unable to move everyone into this space as we had significant resistance to moving to such an open environment from several “legacy” members of the team. However today we restructure our floor plan at least quarterly according to projects and their teams.
Sprint Planning
Initially we rolled with 30 day sprints. However progress was elusive for the team and planning was extremely difficult because our backlog was very shallow. We adjusted to one week sprints and as momentum built we expanded to two week sprints.
Note: Today we still plan two week sprints. We found that one week sprints were too chaotic and sprints longer than two weeks didn’t facilitate enough agility for the business.
Stand-ups
I have struggled with the need for stand-ups from the beginning. I remember meetings where we would go around the horn asking people “What did you do? What do you plan to do? Do you have any roadblocks?” People would just look to the task board and regurgitate their tasks without adding any valuable context. After they stopped talking, we still had no clue as to their progress towards the sprint goals. The stand-up was not meant to be a status report but that is essentially what it became.
Note: Even today we struggle with stand-ups and are working to transform them to contain focused communication that enables the evaluation of progress towards the sprint’s goal. My thought is that if I need a status, I can just run a sprint report and spare everyone the meeting. Yet the meeting is a key collaboration point and discipline so instead of getting rid of it we just need to transform it.
Story Boards and Task boards
We wrote our user stories out initially on index cards and then moved to yellow stickies. These stories were either taped or placed on a whiteboard that had four sections: To Do, In Development, Testing and Done.
Task cards were the result of the user story being broken down into logical development tasks. We initially used index cards, progressed to yellow stickies and then proceeded to have our own custom stickies printed. These task cards were placed on a whiteboard with five sections: To Do, In Progress, Awaiting Verification, Verified and Complete. These cards and their progression across the whiteboards were instrumental in keeping the sprint and its progress in front of the team at all times. This same effect could not be provided via an electronic tool.
Initial Task Board Concept
Note: We eventually got rid of the manual cards in favor of leveraging online tools to track their state, progress and particulars across our process. Yet today we are in the process of bringing back a manual Kanban system to run in parallel with our online tools. Relying completely on our online tool resulted in a significant loss of visibility and awareness across the team, within management and with the customer.
Product Owner
Initially I served as the product owner within the team. I was the one who developed the technology vision and strategy for our pilot project and thus was best positioned to serve in the role. Plus at the time there was not a business analyst on the team. If there had been a business analyst, they would have been the most logical choice to serve in this role.
Note: Today we have a team of business analysts that we actually call product managers. These individuals are collocated with the team and own the release, product backlog and product roadmap.
Looking Ahead
This posting is the starting point for a new and continuing series which will be collected under the Development Process category. Nate Kresse, Graebel’s Manager of Software Engineering, will lead this series and examine the processes, disciplines, tools and vision for Graebel Agile.