Skip to main content

Agile2015: Live Blog from DC

Greetings from our nation’s capital and the site of Agile2015! Robert Woods and Gail Ferreira from MATRIX Resources are speaking at Agile2015 this week and will be live blogging (and tweeting) the sessions they attend. Follow along here all week for enlightening ideas and takeaways from the biggest Agile event of the year.

The fourth day kicked off with a presentation from Dean Leffingwell on the Nine Immutable Principles of Lean Agile Development. Dean went through the tenets of Lean as it applied to SAFe and elaborated on how Deming’s theory and ideas tied into some of his principles. One of the key areas that struck my interest was the discussion of relentless commitment to activities and how to achieve the sustainability of shortest lead time with the best quality and value to people and society, along with high morale, safety and customer delight. Dean went through purpose and execution of Lean Agile development with the focus on using phase-gate milestones to help map integration points together. 

The late morning consisted of a session by myself on Hoshin Kanri which is a way to map Lean strategy into the portfolio model of SAFe as well as other enterprise methods. I had a conversation with Dan Greening on Hoshin earlier in the morning and learned that one of his patterns was using Hoshin principles. Both Ken Schwaber and Dan Greening recommended my session to the conference participants, so there was a nice crowd of enthusiastic lean strategists attending the session.

The afternoon kicked off with a session from Dana Pylayeva on DevOps that included some nice chocolates. Many fun ways to manage DevOps installations were included that were very clear and easy to follow.

The afternoon commenced with Bernie Maloney describing how to Bootstrap your Business Model to Find the Product and Market Fit. The group went through a set of lively exercises and discussions of the business model canvas that helped optimize the business. You can use the Lean principle of “seeing the whole” when visualizing a product.

-Gail (@LeanAgilist)

 

08.06.2015 | 2:44 PM EST

Yesterday I gave my session on the Agile BA and we had a great turnout. It happened to be the only session of the 250 for the conference that was centered towards the Agile Business Analyst. We had some great interaction and experiences detailing common successes and struggles of current BAs. Some of them included the constant question of whether there needs to be either a BA or Product Owner if one or the other exists on the team, and should there be a BA dedicated to a team or just as an available resource. By the end, it was easy to conclude the importance of the Agile BA for their teams and the wave of great Business Analysts coming into the Agile community.

MATRIX also hosted an Agile Open Jam session entitled “Agility in Mainframe and Legacy Environments”. We had a great cross-functional set of attendees with everything from Dev Managers, developers, Agile Coaches and development directors. The initial exercise was to outline all of the ways in which Agility was simply not possible in Legacy and Mainframe environments. Quite a large list was created. We then walked through all of the ways we are currently seeing agility work in those environments. Some of the items identified included mainframe cloud virtualization innovations, innovations in automated testing based on collaboration of cross-functional team, applying principles of Agile in addition to learning how to iterate on COBOL, AS400 and Micropress. One attendee indicated some of these findings “rocked his world”.

Agile2015: Live Blog from DC

Thursday morning I attended a session by Dan Greenway and Jeff Sutherland on Agile Leadership Patterns. There was some interesting high-level information on metrics but the comment that stood out to me the most was the indication that teams should not have more than 5 stories in a sprint and that they should be large stories. His explanation was it helps to eliminate the context switch between going from small story to small story. I’m not sure I completely agree with the suggestion or reasoning. Oftentimes, stories are broken down into smaller chunks which means they lead up to a common theme anyway. That would eliminate the harsher context switching. The smaller story sizes are going to allow for quicker feedback on whether or not we’re right and encourages the “fail fast” mindset. It appeared I wasn’t the only one who wasn’t in complete agreement as some folks left early and weren’t interested in the Q&A with these industry leaders. The session was very Scrum heavy and I think they lost a good number of people because of it.

This afternoon I had the privilege to hear our very own Dr. Gail Ferreira speak on Hoshin Kanri and strategy techniques. Gail outlined areas where leadership can collaboratively look into the future and create realistic goals that help guide organizational performance and roadmaps. As part of the session, she had folks engage in an exercise of using Hoshin Kanri to collaborate at the table on the various areas an organization can create decisions and come to mutual conclusions for future organizational performance.

-Robert (@mindoverprocess)

 

08.05.2015 | 5:11 PM EST

The Agile BA: For an Agile team...You complete me! Bob Woods – MATRIX

This session from my colleague was the only one with BA in the title! Bob discussed how the role of the BA ties directly to the meaning of Agile.

  • Intersection of Product Owner and BA roles, because Product Owners are generally overallocated
  • Need to ensure that we have lean documentation in place 
  • Having a good BA is not like a silver bullet; BAs need to provide the correct business value to end users

Ensuring you have a collaborative process in place to define requirements is of the utmost importance to Business Analysts in order to have a robust set of guiding documentation for the group.

Introduction to LESS for Enterprise Agile – Craig Larman & Bas Vodde

  • Less – Large Scale Scrum – Scale up scrum to any size - 12 years old
  • Any story starts with fear 
  • With LESS, going fast is not as important as going in the right direction
  • Ways of working came from mainframe APL programing (iterative) 
  • Suggested experiments to team to learn what worked and what didn't; some ended up in the first book, some in the second book

Started with feature teams – not grouped around architectural components, but around features in the system. The goal of feature systems is to break the ownership of the architecture and code completely. Take customer centric picture and give to the team – whatever you do to get the feature to work is within the responsibility. Not giving work to the team, but giving them a goal. Whenever there are dependencies between the teams, there are conflicts within the teams. With the team having feature goals, the dependency of goals between teams touches same piece of software, it needs to do this at the same time. Teams need to make sure they are not duplicating work by coordinating and synchronizing work.

LESS – one of the rules is that one of the teams needs to switch from component team usage to feature team usage. Becomes very challenging to organizations with hundreds of members. The contract game has three major milestones – Start, End, Negotiation Complete.

All integration needs to happen during the sprint. Need to find the meaning of the product piece and understand the meaning of the product. At this point in time, there are 600+ experiments that are 3 pages of rules. The difference between 3 pages of rules and 1000 experiments is in a LESS guide. Created the principles of Lean thinking and system thinking for LESS. Some principles to note for LESS include:

  1. Large Scale Scrum is Scrum
  2. Balancing for Agility at Scale is an Art
  3. The one thing that more traditional people need to learn from Agile development is that the concept for tailored down processes is wrong – you need to scale them up

All in all, products end up in default with more processes and features than they actually need, rather than LESS.

-Gail (@LeanAgilist)

 

08.05.2015 | 3:42 PM EST

So far the third day has consisted of many fun interactive sessions that have really gotten the audience inspired and motivated. The morning kicked off with a fun improvisation keynote session that really helped the group get inspired to learn and grow together.

Individuals, Interactions, and Improvisation – Jessie Shternshus

This session focused on the similarities between improvisation and agile. One insight was that Agile development is people focused, flexible and fun.

Agile                                                     Improv
-    Keep moving forward                      “yes and …”
-    Respond to change                         We are all improvisers
-    Honor the vision over plan              Operate unscripted
-    Fail fast                                           Use mistakes as opportunities 
-    Collaborate with Customers            Use Audience Feedback 
-    Scrum Retrospective                       Troop Retrospective

We played a variety of fun improvisation games to provide context for each area – moral is that teams that do not have communication with constant iterative software releases can run into trouble. All breakdowns in an Agile environment do not happen for technical reasons; there is always a people problem and communication breakdown.

Use a Design Thinking culture to approach a shift to Agile culture - Angel Diaz-Maroto Alvarez

Need to create teams for design thinking with different perspectives that can get things done.  The following steps are always applied to ensure that things get completed:

  1. Observe – gather as much information as you can as a team
  2. Prototype (Validate)
  3. Iterate

-Gail (@LeanAgilist)

Agile2015: Live Blog from DC

08.04.2015 | 5:27 PM EST

Pat Reed & Walt Wyckoff - Rebranding the Product Delivery Office

The afternoon kicked off with a lively start by discussing the Importance of the Product Development Manifesto when creating products and services in an Agile environment. Pat Reed and Walt Wyckoff discussed how the PMO can be used to build a better product delivery office, which in turn creates value for the customer. One key goal when building a product development office is to ensure that work is prioritized based on value. Most of the work does not measure plan to value. Project and product managers alike need to find out how the PMO creates value in an organization. The product development model will lead the PMO to the level of value creation you need to create. Earned value is just a measure of cost. The entire team needs to tackle the tough questions regarding how to align and measure value. Agile teams need to spend more time on value and knowledge creation as per Maslow’s ROI hierarchy to “agilize” the PMO.

  1. Come up with a commitment to action that you find to inspire you to do something differently.
  2. Success depends on innovating and evolving constantly in order to delight customers.

One challenge for PMOs is to “unlearn” the way you are doing things. PMO organizations are complex systems designed in the 1900s. A fully flushed out benefits realization plan is needed to create valuable products. You need to understand the importance of MVP and know your hypothesis. Value-based funding is needed for product development. We create our own value debt – we need to take responsibility to acknowledge and change this paradigm. Ensure you ask the question no one else is asking. Doing more with less can actually be a call to failure. Intel has used value dials to transform the perception of technology. Learn how to shape demand, stop waste at the source and only do work that creates the highest value (and nothing more).

Start all work with a benefits realization test plan and use it throughout the process of product development. Teach everyone in the organization how to connect work to strategy using big visual strategy maps. Discuss value delivery office practices.

Eric Willeke – Scaling the Social Fabric of Agility @erwilleke

Eric’s talk was centered around the discussion of how to change the culture of organizations who go Agile. When 50-100 people are in scaled agile projects, processes like scrum lose their soul. Today there are scaling frameworks in place that can be used to help guide the enterprise scaling, but you forget the purpose and forget to change behaviors. The more we focus on how we implement Agile, we lose focus on how the social fabric changes and gets lost.

Eric talked about six key aspects of the problem – and how it is addressed. Who are the stakeholders – who does your process serve? Think of the leadership team and the stakeholders.

Agile2015: Live Blog from DC

First and foremost, “people times process” is important – the assumption that people are running the process. We need to help people be more amazing. One goal important to a scaling initiative is that it’s all about alignment if you have a common goal. There is never such thing as too much communication among people. The following steps should be followed to enable communication in enterprise teams:

  1. Clarity of improvement objectives is needed
  2. Setting the correct goal is key – keep metrics in place to measure time to value 
  3. Two axes of engagement – need function and purpose

In Enterprise Agile environments, we need to enhance the delivery of value or mentoring and growth – which do we organize around and which is the most important? We must pick one of the primary to organize theory. It's imperative to provide appropriate countermeasures to apply practices. Which do you do? Here are some steps to follow:

Need to have a Product Council

  1. Clarify vision and direction
  2. Surface misalignment
  3. Explore future direction
  4. Highlight cross-X decision impact
  5. “Steer the train”

Scrum of X

  1. Make sure you surface cross-X interaction needs
  2. Socialize impediments
  3. Generate trust and relationships
  4. “Keep the train on the tracks”

Architecture Swarm

  1. Request advice and perspective
  2. Share decisions and learning
  3. Escalate critical needs
  4. Surface unrecognized risks
  5. Keep the tracks smooth

Final thoughts: Build a new gang of four – build a leadership team – four key perspectives required for SAFe that includes the Product manager, SA, Development Manager and Release train engineer. Stress having a “team of leaders” and not a “group of leaders”. “Unleash human potential” = "People times Process" – Don Reinertsen

-Gail (@LeanAgilist)

 

08.04.2015 | 2:30 PM EST

I started off my day with Lisa Crispin and Janet Gregory's session on “Introduction to Agile Testing: Everyone Owns Quality”. The key theme was that it is the responsibility of the whole team to conduct "good" testing. Main takeaways:

Whole Team Responsibility - Entire team is responsible for quality and testing

  • Testing on agile projects is more than just testing code; testing is an activity, not a phase
  • Getting everyone together – what level of quality can you commit to?
  • The value of testers and testing – testers add value
  • Importance of collaboration and trust
  • Have a whiteboard and use story mapping
  • Examples, tests, automation
  • ATDD – good acceptance tests
  • Test at each level of the product – Release – Feature – Story – Task
  • The importance of testing quadrants – building it right versus building the right thing
  • T shaped skills – new concept

Important themes that emerged from the audience included – performance operation, analysis, domain knowledge, applications history, systems thinking, many different ways of configuring an application, detail oriented, the unhappy path, writing test documentation, think like a customer, cloud architecture, risk analyzer (prioritize according to risk), flexibility, focusing and defocusing, sense of responsibility (entire team), "quality advocate", audit requirements, collaboration with testing on other teams, understanding business, takes time with different frameworks.

I also attended the session from Nationwide entitled "Data Done Right – Applying Agile and XP Concepts #DataDoneRight"

Key themes that emerged:

  • The importance of IT and Business Collaboration – give them exactly what they want
  • Keep product owner vested in the product – use collocation – 3 amigos – developer – tester – analyst
  • Iteration planning
  • Story cards have acceptance criteria
  • Take technical cards out of the story and break into its own place and build a common and reusable object
  • All story cards have a business consumable result
  • Show and tell – review scenario – show business users what is the current state and future state...In DEV system
  • Nationwide is a large company surrounded by Waterfall projects...
  • Lots of code review and change lists were extremely long
  • Testers understand how the code works
  • Good developers think they are perfect!
  • Growing pains eases with later teams … more experienced person leaves experienced team and goes to a different team. 
  • “Everyone focuses on everything”
  • “Pair on everything”
  • “Break down acceptance criteria”

I attended Dean Leffingwell’s session titled Stalwarts and had a great breakout session regarding Enterprise Agility. He discussed gaps in the current SAFe model and how tools such as Hoshin X and other lean tools can complement his existing SAFe model. Finally, I got his latest book on Enterprise Agility signed and a nice picture with Dean – after giving him my SPC graduation date, he was pleasantly surprised to hear I was one of his first set of SPC graduates.

Agile2015: Live Blog from DC

-Gail (@LeanAgilist)

 

08.04.2015 | 1:45 PM EST

This morning was kicked off by a great session from Al Shalloway, one of the leading voices of Agile. In his session, he outlined areas we need to consider when we want “lean thinking” and a lean approach to delivery. Having a process or framework in place is great, but we have to be real with what the actual situations are. He made an interesting observation in that he had a client with a lot of money available, but that was a concern to him. Why? Because it generally meant they were willing and open to throwing people at the problem as opposed to facing certain organizational issues head on.

Agile2015: Live Blog from DC

I had a chance to speak to Ainsley Niles of Acorn Consulting Group on the subject of Project Chartering and the role of a Business Analyst in that process. As we were talking about the Agile chartering process, we recognized the vital role an agile BA could play in helping to ensure proper translation of business needs into IT verbiage is made and how the natural modeling skills of an analyst would provide considerable value to the chartering and envisioning process and artifacts. This ties in nicely to the session I’m speaking on tomorrow, “The Agile BA: For an Agile team…you complete me!”

-Robert (@mindoverprocess)

 

08.03.2015 | 5:37 PM EST

DevOps at the Executive Forum …… really?

Although the official theme of the Executive Forum was on “Building the Lean Enterprise”, DevOps seemed to be a prevailing theme in the forum (Yes, really! DevOps at the Executive Forum), along with discussions of key metrics and the use of Agile funding models with existing models such as LESS, SAFe, and Scrum at Scale. There was a variety of talks from key executive speakers, along with a lively panel discussion with Dean Leffingwell, Scott Ambler, Jeff Sutherland and Doc Tudor.

Key takeaways from The Scaling Agile Panel discussion (L-R Jeff Sutherland, Doc Tudor, Dean Leffingwell, Scott Ambler)

Jeff Sutherland discussed how to fit Agile practices into the PMO model using Scrum at Scale which created a good solid base template based on good basic key practices, and re-engineering based on the introduction of new business problems.

Dean Leffingwell mentioned that using scaling models requires ensuring that conceptual integrity is applied to any model to ensure that changing business problems are captured.

Doc Tudor said to start with small sets of teams that implement LESS really well, then roll out to the organization.

Scott Ambler pointed out that DevOps Is not developing software, but it is developing business.

Agile2015: Live Blog from DC

Marc Schwartz from the USCIS mentioned how both Healthcare.gov and the USCIS used DevOps to improve productivity. Marc also talked about how to transform large federal initiatives into Agile projects by breaking them into small batch sizes which helps with delivery optimization, as well as estimation for funding activities. Getting the correct funding for federal projects is key, and the ability to manage funding using Lean techniques of breaking work into small batch sizes helps to provide more realistic estimates as well as become more efficient. Marc believed to start at the team level with a group of smaller projects, create a good foundation and then rolling out the product. The synchronization and ordering of initiatives remains to be a key challenge that needs to be addressed when delivering large projects into smaller bits. It's important to get a key metric to track performance and enable organizations to scale.

Randy Sulley from Walmart talked about the importance of the Phoenix Project and how both you (and your security guy) can be present in organizations at the same time. Randy also mentioned the importance of Agile when getting program funding and the ability to size and track performance using key metrics as well. A key challenge in the Agile transformation at Walmart for the executive team has been to break “the founder mentality” and encourage the leadership to let go from a command and control structure to an Agile organization.

Chris Cate from Valpak talked about the Valpak transformation and the realization of slow speed to revenue even though they were doing waterfall really well – DevOps was key here in their metric enhancements after Agile adoption.

Nicole Forsgren from Chef discussed how DevOps changes everything and gave some great metrics based on research in the field showing improvements in productivity. She also discussed how DevOps inspires experimentation, and that failing is not scary as projects can always be rolled back using DevOps. Nicole emphatically stated that “DEVOPS IS GOOD FOR IT”, providing some key statistics such as:

  • 30 x more frequent deployments
  • 200 x faster lead times

Michael Gioja from PAYCHEX discussed the Agile transformation at PAYCHEX along with key metrics, organizational structure, and governance model used at Paychex for their Agile transformation. DevOps was also important for PAYCHEX. Also of importance was the “Pace of Innovation”, which completely transformed the entire development team at Paychex in 2014 to pure Agile. Innovation is a key value at PAYCHEX. Incorporating continuous delivery with small frequent releases to production was key to transformation success.

-Gail (@LeanAgilist)

 

08.03.2015 | 3:25 PM EST

Let’s get right into it! To kick off the proceedings, Luke Hohmann gave the keynote on Awesome Superproblems where he spoke about using gaming in various problem areas within an organization. He used the real-life example of helping the City of San Jose with a budgetary issue that they were able to collaboratively resolve and innovate on with a series of facilitated planning sessions which included city residence and civil workers. It showed the power Agile practices can have outside of software development circles.

Another session I enjoyed was on the need for improvisation in product delivery. Through a subset of improvisation games, the group learned the power behind quick creative thinking and how it can impact both a team and how an organization thinks about its product delivery overall. Sometimes we tend to overthink problems and simply need a degree of more improvisation to allow free creative flow and allow simpler solutions to rise to the surface. I plan to use some of the games we experienced in sessions I host in the coming future!

Overall, a great way to start off the conference. Great to see familiar faces in the group and what appears to be the largest attendee representation I’ve seen yet.

-Robert (@mindoverprocess)

Author:
Solution Category:
Speciality Category:
Tags: