Four Insights from the Agile Dev East Conference

The week of November 14th, I spent 3 days with fellow developers, leaders, and Agilists at the Techwell-organized   AgileDev / Better SoftwareDevOps East Conference and the Agile Leadership Summit. The keynotes and sessions were well attended, as well as the “hallway breakouts.” As a compulsive note taker, I came back with 53 pages of notes, everything from more books on my to-read list, to “Aha!” insights. Here, I would like to share a few of my key takeaways from the conference…

1. Focus on impact

We developed and tested the software, moved the user stories to Done, and collected the Story Points. That’s success – right?


David Hussman of DevJam presented a keynote, exploring the application of Agile thinking to domains in and out of software development, with a focus on product learning and achieving customer impact. In David’s words, “Validation is more important than progress and story points are secondary to satisfied customers.

In our workflow of getting things done, we add one more column: Impact Validated. Did we have the impact we intended? What have we learned from the impact we had as a result of this work?

Kanban board where the column beyond "done" is "impact validated"

How do we achieve this effectively? As we are planning our work, we ask, “What impact do we intend? How would we know if we’ve achieved it?” This focus on discovery helps us learn whether we are delivering the right product or are even moving in the right direction.

Linking "impact validated" back to "ToDo"

2. Scrum is not enough… focus on technical practices

I attended several sessions discussing Agile failure modes and some of the key elements that need to be in place for success in software development. One common theme was technical practices. I will discuss in terms of Scrum, but the point applies to other frameworks such as Kanban…

Scrum is not enough. Scrum…

  • Helps us organize the work
  • Helps us organize the team and the roles
  • Helps us focus on delivering value (and impact!)
  • Reveals impediments and sets conditions to enable learning
  • Doesn’t force us to improve (but – done well – makes it visible if we are not improving)
  • Doesn’t tell us how to do the work

Key agile technical practices, such as the ones in XP, are necessary ingredients for achieving great software results. These could include:

  • Test-first mindset
  • Test-driven development
  • Acceptance-test-driven development
  • Code reviews
  • Test Automation
  • Clean Code practices
  • Unit testing and Refactoring
  • Continuous Integration
  • Continuous Delivery; DevOps

3. A DevOps mindset can raise the bar for process and cycle improvement

Sherry Chang of Intel discussed her experiences and advice for embarking on a DevOps upgrade to the organization. Other speakers discussed various aspects of DevOps and automation. A few things stand out in my mind as things I want to remember and apply…

  • Use Value Stream Mapping to reveal the work and duration components in your workflow. Seeking to optimize for cycle time (receipt of request to delivered software) will lead you to look at the manual steps and queuing delays in the process, including considerations for test and deployment. Automating these aspects of the process take you into the DevOps space.
  • Making the flow through the delivery process visible reveals the bottlenecks
  • Test Automation can be hard; focus on finding the sweet spot of value for automated tests, and consider the overall test coverage (e.g. unit tests as well as functional/acceptance tests) for where to get the best value

4. Conflict is essential

Various aspects of teamwork were of course a big focus of multiple sessions. One recurring theme that struck me was that conflict is essential. This story began with the first Keynote, Andy Kaufman’s, Lead Teams that Deliver the Goods, and ended with Ellen Grove’s, Games for learning about conflict. Andy explored Patrick Lencioni’s Five Dysfunctions of a Team model (Trust, Conflict, Commitment, Accountability, Results). Ellen gave us an experience of conflict, and some playful tools for addressing conflict with our teams. There are a few key ideas that I want to remember and apply…

  • We want the kind of conflict in which differing ideas, needs and motivations are brought into the open and used to forge great solutions. In the process, everyone is committed to the outcome even if their ideas were not used, because they were part of the process. This healthy conflict may be loud and passionate, but it is also clean – it does not cross the line into personal attack.
  • High performing teams have plenty of conflict – and know how to get through it.
  • A lack of conflict on a team is a potential indicator that either the team lacks the necessary trust, or that the team is stuck in artificial harmony. Setting the expectation of conflict, and how it can be navigated, may be a useful part of team formation and maintenance.
  • Many of us (including me) default to an avoidance of conflict – can we get to a place of identifying conflict as riches to be mined?

One of my goals in attending a conference or training is to be able to bring useful knowledge, tools and techniques back to the teams I serve. I committed to writing this blog post, as well as giving an internal Lunch and Learn presentation, before even leaving for the conference. In this case, I found that the built-in accountability for those follow-up steps has helped me to review and mine my conference notes… this has been helpful to me in serving my organization – I hope some of it is valuable to you as well!

Originally published November 29th, 2016 on the Innovative Software Engineering blog. Republished with permission.