Goldilocks and the Seven Bears, the @Pay Agile Development Process

My team is a study in contrasts—the programmers are cowboy coders who are all about moving quickly with an unbridled process. I’m a big fan of rules, organization, and deadlines. What happens when you choose a super-structured person like me to oversee a group of free-wheeling software engineers?

Sounds like it could be a disaster … but it’s not.

I agree with Jack Welch’s point that authenticity is a fundamental key to success. I can’t be successful trying to be anyone other than who I am, and neither can the people on my team. I’m not suggesting we shouldn’t learn from each other and find areas of compromise—there’s plenty of room for that—but a big component of our team’s success is in operating from a place of awareness and respect for our differing styles. We work together to leverage the pros and minimize the cons of each individual contribution.

Before I was assigned to oversee product development at @Pay, the programmers were largely self-directed. The result was competing priorities, half-built features being abandoned, and unpredictable timelines.

I was brought in to bring a bit of order to the chaos; to create a singular funnel for incoming tasks, to produce more realistic timelines for feature releases, and to keep those outside of the development team updated on progress. I’m the person who organizes my closet by color, and my previous career centered on deconstructing and developing solutions for complex issues. It may be surprising, but these skills are actually incredibly useful to our team and the software products we’re building!

It was a bit of a Goldilocks challenge to find a framework that was “just right” for us—light enough for the programmers and solid enough for management. We settled on an agile development process and have implemented some features of Scrum that work for our team.

Now we work in two week time blocks with goals established at the outset and built-in assessment opportunities.

Sprint Planning Meetings allow us to hash out details for all the tasks we’re taking on in the next two weeks.

• Daily Standups give us a quick check-in on where everyone is at, helping us catch issues and blocks before they derail progress.

Sprint Reviews and Retrospectives are an opportunity to see what’s been accomplished over the past two weeks and identify process improvements for the future.

We’re not 100 percent faithful to the Scrum “rules,” but we find the agile development model it presents allows us to balance our simultaneous needs to move quickly and stay on track, providing structure and order while maintaining creativity and flexibility. I think we’ve found a really nice set of tools that work well with our different styles and preferences, allowing us all to be authentically ourselves and achieve maximum success as a team.

Leave A Comment

You must be logged in to post a comment.