AgileDC 2018, That’s a Wrap!

Participants from STSI present a retrospective of this year’s conference!

STSI is a yearly sponsor of AgileDC, the largest Agile community organized event in the Washington DC metro area. As a new member of the STSI team, I geeked out when I was invited to attend.

The conference did not disappoint! It felt like a day long sprint, with session after session of thought provoking material from some of Agile’s finest thought leaders and practitioners.

Afterwards, the STSI attendees shared their unique perspectives and takeaways.

Ben Morris:

From Josh Seckel’s session, I took away the concept of “making people awesome.” It sounds simple and borderline cheesy, but I love that to frame our work: How can we make someone awesome? That might be at the product level (if we build this product well it will help users be awesome at connecting citizens to critical services); or in team dynamics (if I support team members, it will help them be awesome contributors).

Making Agile Work for Data Teams had lots of practical pointers for structuring data-heavy work. What I really loved was how they stepped back to first principles to challenge some of the agile dogma, and find methods that work for these type of problems. One small example: we don’t have to call work “user stories” — not all value is user-facing.

Pratima Giri:

From The Perfect Product Owner session, I learned that product owner should be ranked on these 5 areas:

• Bandwidth
• Power
• Knowledge
• Interest
• Vision

And most important among these 5 component is Knowledge. Another key thing I took from this session is that problems should be discussed early and as often as possible.

From the Revising Retrospectives session: Retrospective is not just a invite in your calendar. The goal of a Retrospective is to improve. So there should be an environment in the team where people feel comfortable to leave feedback. Feedback from the team should always be active and constructive, which means that Retrospective should be blameless. One fun way to talk about retrospective is this idea of mad/sad/glad.

Jeff Farley:

Most of the sessions I attended had great information, here is the easy breakdown from two sessions:

Embracing Endless Change

People don’t like change, but really, that’s all life is, so maybe it would be easy to have some heuristics for dealing with common scenarios.

1. When priorities change, this breaks our focus. Limiting work in progress and deciding at the last responsible moment of what to work on helps address shifting priorities.
2. When products change, this break our plan. Forecasting stories at the epic level and fleshing out details closer to when the work is performed helps address this.
3. When people change or leave, this breaks our expectations. Cross-training and encouraging learning opportunities make everyone less vulnerable to personnel changes.
4. When the process changes, this breaks our routine. Whenever the process changes, start with where you are and make small, continuous refinements to tune and adjust to the new way of working.

8 Elements of Successful Distributed Agile Teams

1. The team chooses between 4 and 8 hours a day of overlapping hours.
2. There should be transparency at all levels. Ask questions in public and not DMs.
3. Have a culture of continuous improvement.
4. Pervasive communication. Important information should appear in multiple channels.
5. When disagreeing with teammates, assume good intent and support psychological safety.
6. The team decides the project rhythm (two week sprints? kanban?).
7. Make sure everyone can start new communication channels and can facilitate ceremonies if needed.
8. Default to collaboration instead of “lone coding”.

Gary Waymire:

Be Kind was the overall theme of day from my POV. Started during the opening session with the announcement of the new DC Agile “Code of Conduct” and seemed to be the underlying message in all of the presentations I attended. Empathy, Selflessness and Altruism are the new core team values. This could be the new millennial input trickling into the workforce. It’s more about job satisfaction and less about competition. I’d like to think that’s the way we’ve all worked in the past, but it’s never a bad thing to remind us how effective teams can work together.

Hina Popel’s Reviving Retrospectives presentation was my favorite session of the day. She was a very engaging presenter and had a great message. Lesson’s learned sessions, no matter what you call them, should be productive and blameless. Her thoughts on problem solving, team empathy, and perspectives were very helpful. Although she may have indirectly called me an Agile Dinosaur 😊. She introduced a tool she uses to constructively collect Retrospective thoughts.. funretro.io . Check it out.

Carol Caputo:

The theme of the day for me was that Emotional Intelligence is important to allow real change on a team. And that Agile Teams HAVE to embrace change

Linda Rising — the keynote speaker set the EI tone for the day with her “Incentives: Why or Why Not?” the carrot or the stick speech highlighting that people are motivated Intrinsically — thus change needs to come from within.

Sanjiv Augustine / Bob Payne of Lithespeed continued down the EI path with references from Herzberg’s 2 factor theory, “motivation-hygiene” that says that there are certain factors in the workplace that cause job satisfaction, while a separate set of factors cause dissatisfaction as well as discussing Daniel Goleman’s “Emotional Intelligence 12 Elements” — they taught us to consider these factors for sustaining change on a team.

Then in my favorite session, Erin Randall — Agile Coach at Schwab and Yogita dhond Agile Coach at Accenture speech on “Can Selflessness Lead to Collaboration?” gave me real tools — not just Story Cubes — to help with team dynamics.

• Build selflessness as a foundation
• Give generously
• Acknowledge when others give generously

Watch now how I start the day — in selflessness and kindness

Michael Chelen:

Managing Technical Debt by Fadi Stephan

Technical debt is a consideration for every software development project, especially as they last longer and the codebase grows larger. This talk provided a framework for analyzing technical debt, and suggested ways to manage that debt when doing project planning, helping you avoid the “We need to rewrite everything from scratch!” situation.

The speaker pointed out that in many ways, technical debt is like other forms of debt. There is prudent and imprudent debt, short term and long term debt, and debt with higher or lower interest rates. It’s reasonable to slowly pay off a low interest home mortgage, while a high interest credit card should be paid off as soon as possible. Similarly, classifying technical debt can help us plan when to take on debt and which debts to pay off first. For example if parts of your code are written in FORTRAN II, that would be a good place to start.

Technical debt backlog

Sprint planning is the time in an Agile process to set development tasks, so it’s the perfect chance to plan for technical debt. When estimating the effort level of a User Story, that effort can vary depending on how many shortcuts are taken during development. I could quickly create a webpage header by copying and pasting the HTML into the top of 5 pages, but updating that header will involve a lot more work later on.

We can reflect this by estimating both a dirty or a clean implementation and estimating the effects a dirty implementation will have on future development.

A sprint plan might look like this:

In this example it’s probably worth the extra 5 points to implement Story A cleanly, since it has such a high ongoing impact. However for Story C would be ok to take the shorter dirty development path, unless we have lots of time left over at the end of the sprint, there are no urgent bugs, prod is running smoothly, pigs are flying, etc.

Code Quality Metrics

Technical debt can build up quickly when trying to meet deadline unless it is carefully managed. Developers might be aware of rising technical debt but it can be hard to communicate to Project Managers and Product Owners. Code quality metrics are one way to display and quanity the amount of technical debt. These metrics include Complexity, Duplications, Code Smell, Test Coverage, and how many comments say “I don’t know why this works.” Once the metrics are established, the team can plan a goal of maintaining code quality during the course of new development. Who knows, maybe it could even be improved!

Example metric definitions:https://docs.sonarqube.org/display/SONAR/Metric+Definitions

Source: https://docs.sonarqube.org/display/SONAR/Visualizations

Conclusion

Technical debt is unavoidable in any real world software project with large teams, complex goals, and deadlines before 2075. The purpose of planning is not to eliminate all technical debt, but to minimize the debt created and to pay off debt as efficiently as possible. Estimating debt during sprint planning helps reduce the debt incurred, and calculating code quality informs the entire team about technical debt so it can be managed, ideally before the bank repossess your Github.

Jim Ramia:

For me, the general theme of the AgileDC 2018 Conference was that we should not assume that we know the entire story on our own. With respect to products, we need to connect with our users and get feedback from them often in order to deliver what is really valuable to them and not what we assume to be valuable.

Here are my 1 to 2 sentence takeaways from the keynote and each session I attended:

Keynote: Linda Rising, Incentives (Why or Why Not)

Don’t assume that a cash reward will be met with equal increase in productivity, the opposite is often the case. Sometimes when you give external rewards, you send out a harmful message that “the thing you are doing is not desirable unless you get some external reward for doing it”. The best incentives are intrinsic.

Roland Cuellar — “Agile for Hardware Dev”

Don’t assume that you can’t iterate on hardware design. Even with hardware design, you can be Agile, getting sample products to a user for feedback on their look and feel. With the help of 3D printers and/or companies that now quickly produce your designs and can add new features or enhancements, you can iterate with your end user just as you do with software and get them a hardware design that is a great fit for their needs.

Lisa Cooney — “Brain Agility — Overcoming Cognitive Bias”

Don’t assume that if you didn’t see it, that it didn’t happen. Being able to focus and tune things out can be a strength but can also be a weakness in that we will not notice many things happening around us that tell the whole story.

Gene Gottimer — “Building The Pipeline Of My Dreams”

Don’t assume that your pipeline needs to use this product or that product to be relevant. Your pipeline should determine whether the software is a viable candidate for production, and if not, why. The tools you use in your pipeline are secondary.

Todd Lankford — “Right product by connecting Agile Team with customers”

Don’t assume you know what your users want. Connect to your customers right away and get them involved with your team as a central force.

Matt Badgley — “Stop Talking, Start Building Trust”

Don’t assume that trust doesn’t matter. The same work that you perceive is rewarding in an environment where you are trusted can be stressful in an environment where you are not trusted.

Scott Showalter/Rachel Whitt — “F.A.I.L. — Fearless Adventures In Learning”

Don’t assume that failure is bad. Try to set up an environment where your team members feel comfortable failing and not one where they are scared to fail. Fail and learn.

See you all next year!