I had the opportunity to attend the annual South Florida Agile Transformation Summit, a local conference bringing together the South Florida Agile community to educate, discuss, and share everything Agile. Here’s my take on this year’s conference:
Scalability, responsiveness, and efficiency are hallmarks we‘ve all come to expect out of well-made modern software. Coincidentally, those three same characteristics—scalability, responsiveness, and efficiency—are now essential attributes we expect out of well-run modern software teams as well.
“But can it scale?”
Ken Rubin kicked off the annual Agile summit with his keynote talk on “Economically Sensible Scrum.” Fact: It’s now easier than ever to start (or convert to) an Agile project team. Pick up one of the thousands of books on Agile project management and get started with tried-and-true, battle-tested ways of getting an Agile team up and running. (Coincidentally, Ken Rubin’s book is the current best-selling Agile Project Management book on Amazon.)
But what about effectively managing an entire Agile organization? Sure, managing one functional Agile team is achievable and well-documented blueprints already exist, but what about a scalable, cohesive, and profitable software organization? This is where most Agile project management books end and, fortunately, where Ken’s keynote begins. The main theme of Ken’s keynote is that core Agile principles applied to individual teams is not enough for an entire organization to be successful—we need to step back and consider the Agile organization from an economic, macro point of view when making decisions.
Going beyond methodology to understand Agile through an economic lens allows organizations to make well-informed, cost-effective decisions. Agile principles are easy to misconstrue and take to extremes, unintentionally bogging down the organization with inefficiencies. Just because Agile states a team doesn’t have to do documentation/requirements up front doesn’t mean you should never do it. Just because you can change directions as a team quickly doesn’t mean it’s sensible to turn a project on a dime a few months before shipping. We have to consider if a decision makes sense in an economic context within an organization.
The underlying assumption in Ken’s proposal is that there will always be waste in a project, but we need to focus on eliminating the most costly and economically damaging waste—and sometimes it can be hard to find the actual source of the most waste. Backing his argument with anecdotal examples, Ken suggested that in order to reach optimum efficiency within an Agile organization, decisions should be made with both Agile and economic principles in mind. Essentially, organizations should always strive to ultimately choose the most financially sound and business sensible option.
Some important takeaways I had from Ken’s keynote:
- Reduce idle work, not idle workers
- Reduce work-in-progress waste
- Reduce overall cycle time with fast flow
- Align project expectations with partners and sales
- Keep high-performing teams together
- Scale and organize multiple teams based on business sensibility and responsiveness, not dogma
Working in an Agile organization that has already implemented many of these suggested improvements, I absolutely agree with Ken. Having actively practiced these takeaways for quite some time, many now seem common sense and almost self-evident. Keeping cycle times low, for example, is nothing new or groundbreaking—this essentially translates into “keep your feedback loop short”, something organizations have been doing since being popularized by Toyota in 1953, or Six Sigma in 1986, and even more recently by Lean. Look at another example: reducing work-in-progress waste. Reducing excessive work-in-progress lowers multitasking and contact switching, which has been proven time over time to be hazardous to an employee’s productivity. Overall, Ken Rubin offered a very insightful look the evolution of Agile and offered useful and practical next steps for an Agile-practicing organization looking to improve.
Old dog, new tricks
Following Ken was a day packed full of presentations. Talks ranged from lectures on forecasting the future of Agile to workshops on establishing trust within a team and everything in between.
Mark Kilby from Rally Software discussing how to apply Agile techniques in a co-located/remote environment
A few trending/recurring topics I noted throughout the day:
- Agile throughout an entire organization
- Continuous deployment and continuous delivery
- Data-driven decisions
Some of my favorite presentations of the conference were about using team-level or organization-level data to analyze and drive business and management decisions.
Prateek Singh, one of my colleagues, spearheaded the data-driven decision discussions, presenting to a standing-room-only audience about data-driven, objective team retrospectives. Prateek demonstrated how retrospectives, traditionally a subjective experience, can also be benefit from being objective by incorporating team data. Using tools like traditional burn-down charts or the more comprehensive Cumulative Flow Diagram (of which I’m personally a big supporter), and even scatterplots, we can analyze team data to generate talking points, reveal insight, and shed light on otherwise overlooked and hidden trends or problems. This data, paired with useful team discussion, can help facilitate and guide the team to make the proper changes in order to improve. As always, implement these team changes in small batches. Supported by real team data, Prateek clearly demonstrated that objective retrospectives are a must-have in any successful modern Agile team’s arsenal.
Prateek Singh presenting on the benefits of objective, data-driven retrospectives
Continuing the theme of converting an organization to agile, Danielle Lopez and Christine Rector led a great discussion about where the role of the business analyst fits in an agile environment. To demonstrate and reinforce the importance of the BA in Agile, Danielle and Christine also led a hands-on activity, having the audience break into small ‘development’ teams, passing out small Lego sets. Half of the groups were to build their Lego set using Waterfall development, and half of the teams were to build the given Lego set using Agile development. All Lego sets distributed were of the same Lego figure. Each group selected a person to be the BA of the group, to read instructions based on their development style. Waterfall BA’s were only allowed to show their team the final assembled Lego picture and answer questions, while the Agile BA’s were only allowed to show the step-by-step instructions (much like an iterative Agile development cycle) and also answer questions. Can you guess which development style finished first? It shouldn’t come as a surprise: Every Agile team finished the Lego figure far before any Waterfall team finished, and with much greater accuracy. What was different between teams? How the business analyst interacted and was utilized during the teams’ ‘development’ process. This hands-on workshop really Danielle and Christine’s point home in a fun and tangible way – the BA is a crucial role within the Agile development process.
Danielle Lopez and Christine Rector discussing the role of the Business Analyst in an Agile Environment
Overall, this year’s Agile Transformation Summit provided some great lessons on effectively managing an Agile team and an Agile organization, and it offered an insightful look as to where the Agile community is headed. The South Florida Agile community continues to grow rapidly, and I’m excited to see where it will be at this point when I return next year.
John Johnson
No comments:
Post a Comment