There’s nothing like a winning partnership to really get you excited about the process of collaboration. We just completed a partnership with iSqFt that was really successful, thanks to both companies being completely committed to Agile software development practices.
Chasing Waterfalls
If you’re unfamiliar with Agile, here’s the two-minute history: In 2001, 17 software developers gathered to brainstorm a strategy to help projects stop failing so often (i.e., delivered late, over budget, and poorly adopted by customers). They broke away from the waterfall methodology, which involved lots of upfront planning, design, and testing in hopes of eventually rolling out a project that was successful. The group created the Manifesto for Agile Software Development, which communicates core beliefs like valuing individuals and actions over processes and tools. Agile is about answering two questions:
- What do our customers want?
- How can we quickly and accurately deliver those features to our customers?
Rule of Scrum
If you’re not philosophically in lockstep when forming a construction partnership, you’re going to have a lot of problems down the line. We started our collaboration with iSqFt by creating one 
Scrum team that combined team members from the two companies to work together, rather than having the two teams working in parallel.
In this “One Team” partnership, our Scrum Team had daily standups every morning. A standup is a daily meeting in which everyone stands up and answers three questions:
- What have I accomplished since the last standup?
- What will I accomplish today?
- What are the impediments keeping me from accomplishing my goals?
Punching the Clock
In nearly every non-Agile software development effort, a project’s length is the main focus. Managers spend several days looking at the project plan and trying to estimate how long each feature is going to take. They often do this without any input from people who actually do the work, which is why these estimates are almost always wrong.
In Scrum, we do team sizing, which means the Scrum Development Team talks about how big features are rather than how much time they are going to take to build. The example often used to explain this concept is t-shirt sizes. Most people can tell you what an extra-small t-shirt looks like versus a medium t-shirt versus an extra-large t-shirt.
We did the same thing in sizing, assigning numbers to features based on how big they were. This was done through a cross-functional team (i.e., developers, testers, designers, etc., from both companies) that collaboratively sized the work.
The actual sizing number assigned to each task is not really the point. The true power of team sizing lies in getting to a shared understanding of the work at hand. By working from this shared understanding between our two companies, our project finished weeks early, and both companies benefited from our mutual success.
Sprinting a Marathon
The only way to measure progress in software development is via working software, and we accomplished that through Sprint Reviews. The premise is that we see what we can get done in a two week period called a sprint, and at the end of that sprint we had a Sprint Review where the team gave demos of what we got done. The Sprint Review gave us a really good understanding of where we were on the project. The Sprint Reviews were also tremendous learning opportunities. We didn’t wait until the end of the project to see if we were on target. We were always updating and sharing our actual accomplishments.
Conclusion
One of the best things about using the Agile software development philosophy and the practices of Scrum in a partnership is that you’re not just partnered at the Development Team level. Our partnership also included executives, sales, marketing, and other business functions by integrating horizontally (across Development Teams) as well as vertically (across company departments). At the end of the day, creating software is an exercise in people, regardless of company of origin, working together to build something. That simplicity is what made the partnership between Assemble Systems and iSqFt so successful.
This blog post is by Anjuan Simmons, Agile Project Manager at Assemble Systems. If you enjoyed this post, please help it spread by emailing it to a friend, or sharing it on Twitter or LinkedIn.
Comments are closed.