The Agilist’s Bookshelf

books-book-pages-read-literature-159866Highsmith, James A. Agile Software Development Ecosystems. Addison-Wesley, 2006.

Agile Software Development Ecosystems is divided into four sections: “Problems and Solutions,” “Principles and People,” “Agile Software Development Ecosystems,” and “Developing an ASDE.” Sections I and II discuss the problems facing the software development world, and delve into how the basic principles of Agile can solve them. Case studies illustrate the concepts, and Section II also presents interviews with the creators of each of the six Agile systems described elsewhere in the book. These interviews shed light on why and how each system was developed.

Section III presents thorough descriptions of the major systems at the time the book was written: Scrum, Dynamic Systems Development Method, Crystal Methods, Feature-Driven Development, Lean Development, Extreme Programming, and Adaptive Software Development. Though Scrum (leavened by XP) has come to dominate the Agile landscape in the intervening decade, it’s important to remember that there are other options and what environments they serve best. Plus, it is interesting to know the history of ASDE development.

Section IV covers “Developing an ASDE.” These chapters are aimed more at enterprise organizations for which scaling issues complicate the adoption of team-level Agile systems. In “Articulating Your Ecosystem,” Highsmith discusses how to determine the key elements of an organization’s culture, and match that culture to the right Agile system. The final chapter, “Designing Your Agile Methodology,” provides in-depth guidance for adapting an existing methodology, or designing one from the ground up.

Every Agile practitioner should read Agile Software Development Ecosystems, from team-level coaches and developers, to managers and executives in organizations trying to adopt—and adapt—Agile.

 

TBSMG, August 2016

This month at the Tampa Bay Scrum Masters Guild, we followed up on the vision for the Guild that we decided on at last month’s meeting:

To take an active role in building up Tampa Bay as a major technology hub.

That’s a pretty tall order! Before we can decide how to make it a reality, we needed to decide how to recognize when we achieve it. We used a variation of brain storming called “Brain Writing” to generate a list of ideas, then used dot voting to select the five best indicators of success:

  • Increase in startup funding for tech companies/actual tech startups on par with major cities like San Francisco or NYC
  • Major technology conferences are hosted in Tampa
  • National media start to report on “Tampa Tech”
  • Increase in tech-related degrees awarded at area colleges/universities
  • IT salaries increase to be competitive with existing tech hubs, i.e., the Research Triangle or Austin

The next step will be to decide what steps to take to make those indicators happen. It’s a topic on the Trello board; vote for it if you want to see more progress on turning vision into reality.

We closed the meeting with a report on the Agile Alliance conference in Atlanta. Sam Falco (that’s me!) talked about two themes that cropped up in several Agile 2016 sessions: making work a safe space for experimentation and innovation, and the future of Agile. Both topics fed into a group discussion of “Modern Agile” and how its four principles map to the values in the Manifesto.

Next month’s guild meeting will be held at Grow Financial on September 7. Don’t miss it!

TBSMG, July 2016

I missed the last few Tampa Bay Scrum Masters Guild meetings, but I was on hand for the July meeting at the offices of Mad Mobile last week. I’m glad I attended, and not just because of the food supplied by Clearly Agile. At this meeting, Adam led us in exercises to refine and clarify the Guild’s purpose, vision, and values.

Why do we meet? What is the purpose of having the Guild? We split into four groups to brainstorm the Guild’s purpose. Each group presented its list. Dot-voting selected a list that forms the peculiar acronym, SLRPN:

  • Share
  • Learn
  • Reassure
  • Practice
  • Network

Guild purpose - dot voting

The third exercise re-visited the Guild’s list of values, created in one of its first meetings. We kept some of the original values, and added more. Look for Adam to post the new list on the Guild’s Trello board soon.

In between those exercises, we generated a vision for the Guild. This exercise aimed to give us a wider goal than the Guild’s purpose: not just “why do we come here,” but “what do we want to be known for.” Once again, each group brainstormed and then put its best vision forward for a vote. The clear favorite was:

To take an active role in building up Tampa Bay as a major technology hub.

Guild vision

To close the meeting, Adam asked for suggestions for topics for future meetings; one of the suggestions was to start figuring out how to turn our new vision into reality. That topic, and a few others are on the Trello board. If you have other suggestions, please add them!

The next Guild meeting will be August 3. Don’t miss it!

Tampa Bay ScrumMasters Guild March 2016

With our captain, Adam Ulery, out sick, Julee Belomo and Christy Erbeck took the wheel and kept us on course for this month’s meeting topic: Fostering Strong Teams. We also had delicious food and dessert courtesy of Clearly Agile.

Helping teams learn to work together can be the most challenging part of a ScrumMaster’s job. In this month’s exercise, we gathered in groups of four or five and considered how to help the team in one of three scenarios.

  • A “cowboy” developer who does what he thinks is best, without consulting the team.
  • A team that limps along, mediocre but unwilling to use retrospectives for continuous improvement.
  • A development team member who, after being promoted to manager, remains part of the team but runs roughshod over them.

All three scenarios reflected real world problems that many ScrumMaster grapple with, and each group generated a lot of food for thought as to how to handle them, and situations like them.

Each scenario also each hinted at something awry at the core of the organization’s Agile practices–it might be worth revisiting them to go beyond, “How do we help the team,” to, “How do we guide the organization to improve its agility?”

We closed out the meeting by soliciting suggestions for the May meeting topic and asking everyone to vote.

At next month’s meeting, on April 6, we will celebrate the Guild’s one year anniversary. Don’t miss it!

Tampa Bay ScrumMasters Guild February 2016

At the February Tampa Bay ScrumMasters Guild, David Corbin, President and Chief Architect of Dynamic Concepts Development Corporation, presented “A Comprehensive Approach to Testing.”

David started by introducing his Axioms of Testing:

  • In a perfect world, testing is a complete waste of time—but we do not exist in a perfect world, so testing is crucial.
  • 100% testing of any non-trivial system would require an infinite amount of resources. You can’t prove a system is defect free.

These foundations served as a launching point to discuss a variety of factors that go into creating a comprehensive testing infrastructure. Topics included:

  • Forces that drive testing
  • What do we test
  • When do we test
  • Guiding principles of testing

David will present “A Comprehensive Approach to Testing” at the South Florida Code Camp on February 20th.

The next Tampa Bay ScrumMasters Guild meeting is March 2.

Tampa Bay ScrumMasters Guild January 2016

If you didn’t attend the first Tampa Bay ScrumMasters Guild meeting of 2016 last Wednesday, you missed out on several new faces, announcements about Bay Area job opportunities, and a thought-provoking presentation about “Holacracy,” by Ingrid Bredenberg. Ms. Bredenberg is an organizational development expert and a self-described Holacracy evangelist. Spirited questions and discussion punctuated the presentation, and many Guild members left eager to learn more.

Holacracy distributes authority away from a management hierarchy, across teams and roles “energized” by individuals who execute their work autonomously. Holacracy provides a clear set of rules for how teams break up their work, and defines clear expectations and responsibilities for each role. The rules apply equally to every member of the organization, and provide methods for resolving tensions about what must be done as those tensions arise.

Information about Holacracy is available at holacracy.org.

Ms. Bredenberg stated that her presentation would not make us better ScrumMasters, but I disagree. Learning about different ways of organizing and thinking about work stimulates our critical and creative thinking in ways we can use as we guide our organizations toward greater agility.

The next meeting is February 3. Mark your calendars. You won’t want to miss it!

Farewell to 2015

2015 was the second most tumultuous year in my life. I lost my job at the beginning of the year, made a mistake in taking the first offer that came along to replace it, and struggled to retain a positive outlook and find my way forward. But I used the turmoil to find my way to the career I really wanted.

On January 19, a corporate restructuring eliminated my entire division. I tried to be optimistic. The severance package was generous, my skills were up-to-date, and I’d long wanted to find a new job, anyway. Maybe this would be a good thing.

Still, I worried, and my worry grew when, a month after the layoff, I hadn’t had a single interview in spite of sending out dozens of applications, working with multiple recruiters, and giving myself headaches searching career web sites. Then a developer who’d been canned along with me contacted me. He’d found a job. Send me your résumé, he said. They want to become agile. They need you. I had some trepidation after the interview process, but the offer they made came close to replacing my former salary. I let fear of being out of work override my concerns about whether they really wanted to be agile. I took the job.

My concerns proved well-founded. “Agile” was nothing more to them than a magic incantation that meant everything and nothing. I tried to introduce Agile principles, and was rebuffed at every turn. A month after I started, the CTO presented the new SDLC process he’d designed without any input from the people who would be expected to follow it. I pointed out that there was no provision for retrospectives. His response? “Sam, I never look back.”

He wasn’t joking. I started looking for a new job again that day.

Once again, I sent out résumés, worked with recruiters, and searched job boards. Once again, it did me no good. I needed to find a way to stand out. I’d been an acceptable Scrum Master at my previous job, but “good enough” wasn’t good enough. I needed to be great. I wanted to be great.

I signed up for a Certified Scrum Product Owner course. I didn’t want to become a Product Owner; I thought it would make me a better Scrum Master. It would help me better support the Product Owner at my next job, wherever that might be.

Meanwhile, I looked for other Scrum practitioners to learn from. I read. I engaged on Twitter. And I discovered Tampa Bay Agile. Through “Lean Coffee” meetings and monthly Scrum Masters Guild meetings, I connected with other Agile thinkers. My understanding of Scrum expanded exponentially and I drew inspiration and energy from the people I met.

In September, salvation arrived. A Scrum Master position opened at a company in Clearwater. I got the job. I took a week off between jobs to write in my journal about what I’d been through and how it had affected me. I wrote about how I would leave the negative energy and thought patterns behind. When I had processed all of those negative emotions, I wrote about what I hoped to accomplish, and planned for how I would continue to grow my career in my new job.

It’s been not quite three months, and I’ve adapted very well. That’s not to say I still don’t have a lot to learn, and plenty of growth ahead of me, but I’m eager for it. I’m energized by the challenge, and happier at work than I’ve been in years.

What I went through changed me. I could have let it beat me down, but I chose to find a way to move forward. And with what I’ve learned from 2015, I know that there’s no reason I can’t achieve even greater success in 2016.

3 books that should be in every Scrum Master’s library

The Scrum Field Guide, Mitch Lacey.
Although it’s subtitled “Practical Advice for Your First Year,” Mitch Lacey has loaded his book with so much good advice that even veteran Scrum Masters will find themselves reaching for it from time to time, especially when creating new teams or joining a new organization.

Succeeding with Agile, Mike Cohn.
Another excellent resource for Scrum Masters introducing Scrum to a new organization, including lots of advice on how to start from scratch in companies that have never been Agile.

Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland
Jeff Sutherland helped create Scrum, and his recent book explains not just what Scrum is and how it works, but how and why it was designed the way it was. Any Scrum Master who has been stumped by questions about why a Scrum ceremony or artifact is important will find the answer here.

Scrum and Quality

As a Scrum Master at my last job, I often interviewed developer candidates to judge their experience with and appreciation for Scrum. Almost all had some experience with it, and opinions were mixed. Many were non-committal. Others rhapsodized about it. And one told me she hated Scrum, because “It’s a waste of time.”

Of all the complaints I’d heard about Scrum, this was a first. Scrum a waste of time? I asked her to elaborate.

“You have a two week Sprint, and deliver the code, and then you wait around doing nothing for two weeks while QA tests it and tells you whether it was accepted or not.”

I assured her that what she described was not good Scrum practice. The Scrum Guide states that, “A new Sprint starts immediately after the conclusion of the previous Sprint.” She didn’t see how that was possible. How, she wanted to know, could code be considered complete before QA had blessed it? How does Quality Assurance fit into the Scrum development cycle?

“Scrum recognizes no titles for Development Team members other than Developer,” states the Scrum Guide, and Scrum also does not recognize sub-teams. The team should be cross-functional, and can accomplish its work without relying on people who aren’t part of the team. Does that mean that a Scrum can’t have testers? Of course not. Scrum recognizes that “Individual Development team members may have specialized skills and areas of focus,” including testing. It just means that testers have to be fully part of the development team, and code should be tested throughout the development process, not at the end of a project. What this woman had endured wasn’t Scrum—it was miniature Waterfall with a two week development phase. No wonder she was turned off by it.