December 26th, 2012 | Katie McCroskey
Lessons learned at Agile Coaches Camp 2012
Agile Coaches Camp is something I look forward to every year: catching up with familiar faces and friends; hearing everyone’s horror stories, funny stories, accomplishments and successes, and most importantly – lessons learned over the year.
It is two days of education on a vast array of topics, from shaping team culture, Agile engineering practices, Scrum vs. Kanban, dealing with a difficult team member and complex Enterprise Agile issues. There is a topic of interest for everyone, that’s because the group picks the topics – there are no premeditated sessions and no prearranged speakers. Whatever happens at Agile Coaches camp was supposed to happen – the right people are there, and the conversations flow as they are meant to flow. I always leave feeling inspired.
Personally, my goal of Agile coaches camp was to explore Agile organizational culture and team environments. Well-built Agile teams operate seamlessly – with effectiveness and precision. Team dynamics are a crucial piece to the puzzle – there also must be respect and the willingness to help. The overall dominating perspective regarding Agile teams is that the whole team succeeds and fails as one. But here comes the challenge – how do you create that type of Agile team environment?
Through first-hand experience, great conversations at Agile Coaches Camp, and a few books read – I’ve come up with a few key factors that contribute to developing a strong Agile team.
First, the right people are important. It takes the right personalities, professional skills, individual drive, and willingness to work in a team environment. Another critical aspect of an Agile team is its never-ending drive to improve and status quo is never acceptable. This constant creation of change and continual learning in an Agile environment is typical. Stepping outside comfort zones is crucial for growth but isn’t always for everyone. It is this desire to change, grow and learn that builds great teams and experienced people.
Another important element to an Agile team is the ability to self-organize. Natural leaders emerge and there has to be enough trust, respect, and team buy-in for the team in order for this self-organization to occur in a productive direction. Simply, one weak link in the chain can disrupt the productivity of the unit and break the bond for the entire team.
Overall, the key to successful Agile teams is the overarching mindset that the team fails and succeeds as one unit. This concept can be applied to all shapes and varieties of an Agile team – from a team of developers/analysts/testers/designers to an entire organization that operates reflecting the Agile mindset.
March 25th | 2010
Two Week Tetris: Applying Otazo’s Truths to Managing Development
Managing a development team is a lot like maneuvering falling blocks in Tetris; the blocks of work never stop, they often need to be rotated mid-course, and as you go the shapes don’t always easily match up.
Applying the “truths” from Dr. Karen Otazo’s book, “The Truth About Being a Leader”, is effective for meeting the challenges of coordinating development; it offers key advice for maximizing your figurative score. As team lead for the product team, I manage a two-pair development team that tackles fixes and features for our company’s products. Being an Agile shop, we use Test-Driven Development with paired programming and a Scrum sprint structure. The main responsibility of a team lead is to produce high quality software at the fastest sustainable pace. Using a modified Scrum process, we employ a two-week sprint system where the development calculates points (block of work) for each story (requirement / feature) from the product owner and ultimately commits to getting a chunk of points/stories done for that dev cycle. It is these blocks of work that come off feeling like Tetris with the goal to clear the stories from the task board getting them all to “Done” (Code Complete, Reviewed, and QA’d). Otazo’s truths on the Player/Coach role—sharing forward thinking and managing the mental bandwidth—offer insight into winning in a leadership role.
Maintaining the Player / Coach Role
One of the challenges of a team lead is the constant straddle of the Player/ Coach role. Karen Otazo summaries this with Truth 8: “Player/Coach is a Tricky Role, So Make Sure That You Do Both Well” and questions when you should focus on being a player and when being a manager, to maximize the team’s output. Our team’s paired programming format helps me integrate with the team and gives each developer a voice for their own creativity and innovation. When pairing, the team lead is in the player role and has to defend his code choices and be open to alternative approaches. Pairing provides the benefits of learning from the lead’s experience while fostering the best collective approach. In the management role, the focus is on tracking the stories that are being completed, keeping the queue full, and occasionally stepping in on a pair disagreement.
One way I keep a successful flow of the task board is by sharing my vision of the events coming up next. Otazo makes the case for this with Truth 19: “Playing Out the Tape Helps Others Prepare for the Future.” Truth 19 argues effective leaders learn to fast-forward by establishing a vision of what they see the future being. During the development sprint this means steering in the right blocks of work and expressing what would fit best for the next block. The taskboard is also designed with this in mind. By having, in addition to the In Process portion, the On Deck stories for the next chunk of work and the backlog visible, developers can get a quick sense of what’s in the pipeline. Telling the team how I see the board playing out helps the team get more lines cleared and avoid the gaps that form as developers remain focused on a single work stream.
Fill Your Mental Bandwidth
I have found Otazo’s first truth to be both necessary and demanding ; “More-Responsible Roles Require More Mental Bandwidth.” Most of my responsibility comes down to keeping track of everything for the development space while mentally organizing the requirements to stand in for the product owner and the customer. Going from developer to team lead, I have a new appreciation for the coordination that is required in all the stuff outside of getting the development done, and the significance of brainstorming / prep for the next sprint. Being able to maintain a handle on all the moving features and issues keeps the team on the right path and allows the product owner to trust the production process.
My Truth: Avoid Too Much To Clear
My advice is: put thorough thought into each story to obtain an accurate estimate, and avoid the clog of “almost” finished stories. When we take on too many stories or fail to plan completely for difficult tasks, just like Tetris, the task board is full of tasks and stories in process, but too full to be able to clear them all out by the end of the cycle. The stories on the board take on an oblong, ill-fitting shape, as Developers would much rather start a new code task than pick up code review or QA. The tasks don’t get cleared to Done and this quickly sours the sprint as every story is code complete but QA has to be carried over.
As team lead, I help mitigate the choke points by providing direction for the constant goal of clearing a story before taking on another one. By limiting the items in process or number of items allowed in a column, such as in Kanban, I keep the team driving to pull a story all the way across the board. And by implementing a proper planning phase and continually striving to complete the row and clear that difficult line—I achieve a consistent flow.