Agile Practitioners 2015

After last year's conference, the guys from Practical Agile decided to "open source" the conference - the conference was community driven by a volunteering steering team. This year the conference offered a full 4-track program under the title "learn something new" making it harder than ever to choose the sessions.

Keynote: Unicorns, krakens and self-organized-teams

a delegation board

A slimmer version of Angel Medinilla (@angel_m) returned to get things going with his high paced, humorously sketched view on the road (and pitfalls) to hyper-performing teams. Some of the notions come from management 3.0 which is not a coincidence, as Angel is one of the M 3.0 trainers. Some topics to follow up on may be the Agile Fluency Model, the "Agile Kaizen" book and delegation boards.

Morning Sessions

Gil on #NoEstimate

Gil Zilberfeld's talk, “To Estimate or #NoEstimate” talked about the #NoEstimate movement, why people want estimates, what are the problems with estimates and what could be useful alternatives.

Meanwhile I missed, among others, Uri Nativ's "Missing Lecture" about the difficult-to-deal-with gap between the agile coach/leader's perspective and the teams' view on the agile change initiative. I love the slides (form and content).


Next, Lior Friedman, talked about code smells, and their less (in)famous cousins: Test Smells. Learning to identify them can help improve the system. After all, TDD is a way to write well designed software. Problems in the tests often tell you of problems in the design, or even in your process.

Afternoon Sessions

Three short sessions:

One of Barak's slides

• Gull Ben-David (from MyHeritage) shared why QA people make good scrum masters
• Ran Deri and Noam Zweig (from CyberArk) gave some insight on their experience dealing with Technical Debt systematically. Interesting mix of tools (such as sonar) and assessment (using a survey by Gil Broza) to actually track, negotiate budget and set goals.
• Barak Benjo (Cisco) gave tips for Agile Testing in a legacy environment

In a session I missed, Yuval Yeret (happy birthday!) gave a talk about an effective way for managing an agile transformation.

"Lean Lens" - observing our results

Andrea Darabos conducted her "Lean Lens" workshop. It is essentially a role playing game each team gets a scenario to play out. Some participants act, simulating the different roles, while others observe, trying to identify the 8 types of waste (better known as the 7 wastes + unused skills).
You can download the game here (developed by @bazila and @ADarabos)
Interesting takeaway - try set up a board in the team room to collect instances of the 8 wastes as they happen, and deal with them in the retrospective. Hey - these are "process smells"!

Meanwhile, Eyal Golan talked about working with legacy code. I was told it was interesting and practical.

The last track session actually had 5 options, because Angel agreed to give an improvised sketching workshop where we practices some basic shapes, faces, stick men, containers, call-outs, etc. That was fun, and it was similar to some of Angel's Drawing 101.
More advanced stuff can be found in learning to sketch on tumblr.

Closing keynote: Claudio Perrone on Popcorn Flow and A3 thinking

Claudio, a.k.a Agile Sensei, described his A3 thinking / problem solving system, and POPCORN flow, which is a kanban board for capturing, planning and tracking change experiments.
Slides here (well, very similar to the ones he actually used). Another interesting concept he described was "job to be done" (JTBD) as an alternative to user stories formulation, focusing on the human need you wish to fulfill. As an intro to the topic, Alan Klement's description of a "job story" is very useful.

There was much more, obviously, but that's what I can share. Great stuff, community!
You can find more here:

• Dror Helper's impressions of the conference here
• Gil Zilberfeld shares some stats (and a creepy photo holding Dalia's disembodied head)
• Twitter handle: #APIL15

Packing List for Your Agile Journey - Change

The Ten Speakers in the Series

Packing List

Today Gil Broza interviewed me about "embracing change", as the 9th interview out of ten hour long interviews in his series called: "Packing List for Your Agile Journey".
Subscribers get the ability to listen live or offline, access to transcripts. Gil asks each speaker to focus on one topic, so the overall series has a great balance of topics for listeners who want advice and ideas for starting or improving an agile implementation.
The topics are: Organizational support, enabling collaboration, feedback loops, whole product thinking, quality, technical excellence, get-to-done mentality, culture, change and values.

Some of the Things We Talked About

Gil asked me about change - how agile helps you deal with change, what types of change do we deal with or worry about, how did we (and still do) change an organization to become agile?
Some of the insights I can now recall without having a transcript of the call:

• People don't really resist change. They resist change that's imposed or seem arbitrary.
• Agile is designed to deal with changes in what you do, and encourage you to change how you do the work. It's less prescriptive about how to change to agile, which is essentially a cultural change
• Understanding and buying into the values and principles of Agile is much more essential than mastering a specific practice or ritual. Going through the rituals mechanically is equivalent to a "cargo cult", and will yield very little improvement, if any.
• Working in a large and distributed organization such as Software AG, there were a few observations:
• Sometimes a cultural difference is felt more after a merger/acquisition, than across geography and nation
• The challenges include quick integration of products, organizational changes (due to M&A), and building and maintaining trust when people are in different locations and timezones
• Having a senior manager who "gets it" and can point the direction and set priorities is invaluable 
• We have a "Change Agents" team who represented all locations, got together and got deep coaching and continued to function as a virtual team. This team was very helpful quickly getting the whole organization to learn the principles and coach people to start experimenting with the process. It also helped building trust across locations.
• We invested much in values, culture, lean principles and teamwork training - more than any specific practice
• Push back if you feel you are about to do something dumb
• A Responsibility stance (Avery) or Being Proactive (Covey) is essential to successfully dealing with change 

I'm likely to update this page after having the transcript to maybe reflect the content a bit more accurately.

More Questions

I'll be happy to get comments on this post from anyone in the audience who'd like to expand on anything I mentioned or ask more.

Software AG at Agile India 2014

On January 2013 I had the great experience of sharing in Israel some of what we learned at Software AG during our ongoing road to Lean and Agile, and I know of a couple of other colleagues who presented at other conferences.

Last week, Bangalore hosted the Agile India 2014 conference. Four days packed with speakers from all over India, and many international speakers. This time, my colleague Harish Krishnaswamy was presenting a very different perspective of our story. You can find the slides here, or read the full experience report which is packed with information and inspiring data of the significant impact of the transformation. I recommend to people interested in large scale transformations - read the report. Harish did a great job collecting information and interviewing many people in different roles regarding the journey. I'm sure people of Software AG would find it interesting to read a story they played a role in from a different, more holistic perspective.

An impressive amount of four more Software AG employees gave lightning talks: Amit Deshpande, Heartin Jacob, Chandan Ravishankar and Ramya Gopalakrishnan.

Amit spoke of Scrumban, a combination of Scrum and Kanban which can be used in those circumstances where you have a mix of feature development and technical debt/customer issues. In particular customer issues or unplanned events that could be disruptive to the planned work in a sprint.

Heartin blogged on the topic of his talk: what success means in Agile and how Agile helps us to be successful, highlighting the strong bond linking technical and organizational success with the personal success of individual contributors. 

Chandan asked why are you following Agile? The key point is that following the practices becomes an empty shell without being a part of the transition, caring and having personal engagement with the work you do (aligned with Heartin's theme). Another is the point that agile practices are designed to keep you honest about what you can deliver on a sustainable pace, and encourage you to aim higher based on the current reality and your history.

Ramya talked of using WIP limits to reduce Context Switching, sharing the specific context and behaviors the team adopted to deal with complexity, reduce stress and maximize learning and collaboration. I'm not sure how common it is to do an exercise with the audience demonstrating context switching in a five minute lightning talk and still have time to say something - wow!

Such evidence strengthens my belief that the transformation we're going through at Software AG runs deep - many individuals align with it and contribute well beyond their job description for the success of the organization, for technical excellence and in support of their own growth.

Upcoming Agile events to look forward to

I've been on a break from blogging since my daughter's birth, but here's a heads up to some events I'm looking forward to and expect to write about.

Agile Practitioners 2014 conference events this week:

1. 28-Jan-2014 - Workshop: Jutta Eckstein, on ‘Agile Software Development in a Large and Distributed Environment’
2. 29-Jan-2014 - the Agile Practitioners 2014 conference day - here's my post on it
3. 30-Jan-2014 - in the spirit of "Code Retreat" and "Coach Retreat", the first ever "Retrospective Retreat"!

Yet, it doesn't stop there! The week after, on February 3rd, Dave Snowden will be giving a talk "Complexity in human systems" at SAP labs.

Stay tuned :)

Agile Manifesto for Kids

This Sunday my daughter was born. While I'm busy with getting used to pink (after two boys) and until I blog again, I leave you with this. Feel free to download, print, connect the dots and try to identify who's who :)

If you didn't get it, you probably could spend more time here.

Collaborative office space

In preparation for some changes in our office layout, I was interested to do a little research on various ideas on the topic.

Caves and Common

In Agile Software Development (2nd edition) chapter 3 (and 3.1), Alistair Cockburn describes a possible office layout - with the team room (programming room) having a central cluster of tables where pairs sit facing the center, with some more private areas on the side of the room. This is known as "Caves and Common". There's research backing this up in the book, rephrasing the Allen Curve (communication exponentially drops with distance) as the "school bus rule".
That's the typical agile team room (blogged by Martin Fowler).
This is sometimes also called a War Room.
Another blog that argues for this setup with lots of references: The Ultimate Software Development Office Layout

Inward facing U-Shape

Another setup. Well, it probably goes with an open space for multiple teams. Cool idea of joining a whiteboard and special projector. Each team member can share their screens on the team board with a single button press.

U-Pod

Martin Fowler blogged about another option of a U shaped space, where people face out side. While it is easier to roll over towards each other, it is harder to find a place for a team board. And avoid the corners, bad for pairing.

Here's a recommendation by someone who tried it.

This is sometimes referred to as "The Bullpen".

Half Height Cubicles

Richard Cheng recommends half height cubicles. His slides show some additional options, considerations and aspects (I think he's missing the point of avoiding the corner made by Martin Fowler). In context of his slideshare, I think this is evangelized as an improvement to the previous single person cubicles. 

The Bionic Office

Right... Cool, perfect for focus and personal effectiveness, but totally optimized for working alone, inhibiting communication and collaboration.

After the first wow effect, agile teams optimize for team results rather than individual performance.

Overviews

Dafydd Rees (the programmer) shares his experience with different arrangements covering more or less similar setups.

InfoQ cites Mike Cohn on Workspaces for Effective Agility - not so much about the physical layout, but some aspects to take care of.

My Conclusion

There are many variants, and some would be more effective than others depending on context, individuals, team size, company culture and office constraints. You'd want to consider:

• Ease of communication
• Ability to focus (reduce distractions)
• Team ownership of the space (use of information radiators)
• Adaptability when needs change

Oh, and don't sit in an L shaped corner if you're ever going to pair...

What's your experience with various office setups?  

Update:
A short clip case studying the Stanford design school, and their concept of the impact of the work environment on learning, engagement and teamwork.

Absolute Teamwork

I've been interviewing a number of candidates for our team recently. Almost every CV contains some pseudo-mandatory clause about great teamwork skills. I was wondering what teamwork meant for these people. So I asked. Too often, it doesn't sound much like a team.

My reference for the concept "teamwork" in the past year and a half is a team called "the Smurfs".  I was fortunate to have served as their scrum master for a few months when the team was forming after joining two teams together, and held a management role throughout the long project.

Things I love about Smurfs

Helpfulness

The team has a distinct culture of asking each other for help and being immediately available to provide help. It's essential for doing peer code reviews, for getting new team members on board and for knowledge sharing. A special role of an "on duty smurf", a fire fighter dealing with customer issues and test failures for a whole sprint, allowing the rest more focus, is  unlikely to have been possible without this helpful spirit. 

Respect

The team continuously demonstrated respect for each other. One aspect of it is that being passionate about the work led to passionate discussions. These were not ego driven, "my idea is better than yours" type of discussions, but rather real exchange that actually included listening. I could see it in technical design discussions, and in retrospectives alike.

Experimental Approach

A few examples:

• When I stepped down from being a scrum master, the team tried to distribute the SM role between team members despite the consistently ominous warnings by non other than Jim "Cope" Coplein. It was a grand failure, many lessons learned, and a quick and successful recovery by identifying their next SM
• The team kept trying out different new tools to support it's work - dashboards, testing techniques, clever code coverage measurements, experimental debugging techniques 
• Being in the context of an enterprise level R&D, other teams benefited from the team's knack for improving tooling - many improvements to the main issue tracking system were made based on their feedback, and a whole new tool was introduced that supports code reviews, especially for distributed teams
• A rich physical task-board (see prezi!) with many cool and useful ideas  
• Convinced the office management to bring down a wall for us, to have proper space for a daily standaup
• An evolutionary approach to discover how to deal with different types of work, specifically customer defects (described in my talk I gave at the Agile Practitioners 2013 conference)
• Acceptance Test Driven Development (ATDD) - the whole way we define our stories was modified based on ideas a few team members brought from an Agile-Testing workshop 
• Working together - swarming on work, by priority, was yet another experiment early on, that turned into a habit

It all boils down to safety and trust. Without a sense of being trusted, people are less likely to help or ask for help, and to experiment individually and as a team.

Last, but not least: fantastic results!

Besides the dramatic improvement in the response time to customer issues, the improved test coverage (quantity and quality increased), and quality - a new and exciting set of features, nicely balancing highly sophisticated capabilities with a rather straight forward user experience.

Thanks

I'd like to acknowledge and thank the individuals who demonstrated to me what's teamwork.
The Smurfs team in this project are (in alphabetical order):
Dganit Keidar, Gad Salner, Ichai Luzon, Idan Zohar, Marwan Jaber, Michael Adada, Oded Nehama, Ofir Laviad, Ortal Balter, Rosalind Eidelheit and Yaniv Mualem.

Strongly affiliated and supportive of this team, locally: Assaf Appel who served as the Product Owner, Gadi Benedek, Asaf Broide and Lior Yaffe, together with a good number of people from the administrative staff. From Germany, we enjoyed the further support and collaboration with Andreas Goermer and Oguzhan Oezkut. And speaking of safety and trust, there's a big doubt if things would look the same without Christian Gengenbach, our VP.

The Smurfs continue to their next project in a different format. I'm certain they won't settle for anything less.

Re: Is it Safe to Fail?

Amr Elssamadisy (@samadisy) recently blogged, asking Is it Safe to Fail?

I strongly agree with his claim (and I paraphrase here) that the "skill of failing" is an essential factor in a team's ability to learn and improve. 

Interestingly, Amr identifies three categories in which this skill is cultivated: culture, individual human dynamics and agile practices:

1. Leaders create a culture that rewards small failures and the successes that come after them. They celebrate the successes and failures and lead by example.
2. Individuals understand that failure is a milestone the road to success. They have experienced it multiple times and are not intimidated by it.
3. Teams use software development practices that make failure SAFE.

While Amr elaborates on the third category, of practices (such as TDD, TDR/BDD), I want to explore a few options on the first category. What could be the elements that support such a culture? It seems to me that the second category emerges out of the other two over time.

Cultivating a Learning Oriented Culture

How can leaders cultivate a learning oriented culture, one that expects such failures?
Here are a few concepts that with proper teaching, coaching and leading by example, can serve as foundations to such work environments.

Responsibility Process - out of the Blame Game

Christopher Avery (@christopheraver) and others developed the Responsibility Process. In a nutshell (seriously, I can go on for weeks about it), this is a psychological model about how human beings deal with problems. Being aware of it, one can acknowledge the tendency to react out of a blaming mindset, and choose to hold on until a better, more effective, state of mind is reached. The model describes a number of distinct mental states that are normal for humans to have, but might not be ideal to be in when trying to take action. Responsibility is the desired mental state - in which one has learning capacity, resourcefulness, eagerness, energy and courage.
The model is a powerful tool for self awareness and mastery, but better yet - it can be a great way for a team familiar with it to have a shared language to make working agreements that support learning, trust and safety.

Nonviolent Communication

NVC is the brain-child of psychologist Marshall B. Rosenberg. It is aimed to show an alternative for the highly judgmental and competitive education most of us had.

During Agile Israel 2013, Bob Marshall explained violence using the acronym FOGS.
Violence is using or triggering one of the following emotions in others, to make them act in a certain way:

• Fear
• Obligation
• Guilt
• Shame

With this definition in mind, consider that many processes are violent due to their implementation. Why should we care? It might be the wrong way to reach our goals, to meet our needs.
Bob went on to describe NVC as a 4-step process, with a pre-requisite of empathy which is essential for diffusing a conflict situation. Try to understand the other side in an explicit way (or fake it...). The next steps are:

1. Observation - what are the facts
2. Feelings "how did it make you feel?" 
3. Needs - violence originates by needs not met. What needs that are not being met cause those feelings? (or needs that were met, for positive feelings)
4. Request - "would you be willing to..?"

A First Glance Comparison of the Two

I thought of introducing The Core Protocols as another culture hacking approach, but it suddenly hit me how similar NVC and the Responsibility Process are. I'd like to dwell on it for a moment.

Violence in Rosenberg's world is basically all that the "non-responsible" positions of mind are made to deal with. These are all coping mechanisms against the abundance of violence others emit. But this is poor protection - the aggressive party gets to "win" by triggering Shame or Obligation, forcing someone to action with fear. However, a person reacting out of Responsibility can distinguish between the stimulus (observation) and her own emotional state (feelings) and confront her own wants (needs) before picking a response.
The key difference (based on my very limited knowledge of NVC) is that while Avery's Responsibility is more about one's own state of mind, NVC is about dealing with others while dealing with ones own state of mind and creating an environment that supports the other to reach a Responsible state of mind.

Wait - How does it Relate to Safety?

Assuming the similarities I find between NVC and Responsibility aren't too far off, introducing such concepts (teaching, coaching and continuous practice and demonstration) to any community would raise the levels of trust and safety, and therefore of healthy, effective, honest and open communication. Roughly I'd say Responsibility is a tool for the individual to be more resilient and brave (inherently safer) while NVC is designed to reduce the levels of violence, therefore making it safer.

Thanks, Amr, for raising the topic of safety as an important factor for effective teamwork. It is also an ethical issue - there's little joy at work if you don't feel safe. But if you had to choose between implementing processes and practices that might generate some safety versus changing the culture - what would be more effective and long lasting?

Update: Amr recommended this blog post explaining Tech Safety - I love the concept, though the focus on the word safety might create an impression that it is not about quality, joy and respect for people. It is.

The Joy of Social Networks

In my post about the Agile Israel 2013 conference I mentioned Bob Marshal's keynote, and his principle of "Joy for All". I wanted to link it somewhere, but couldn't find more. So I found myself having the following twitter conversation with him:

1. 
   

   Guy Nachimson ‏@guynachimson18 May

   
   

   @flowchainsensei Did you ever blog of your "joy for all" guiding principle? I can't find reference to it as such

   Expand
2. Bob Marshall ‏@flowchainsensei19 May

   @guynachimson I don’t think so, directly. You can find the roots of it in e.g. Rosenberg’s spirituality of NVC http://www.cnvc.org/learn-online/spiritual-basis/spiritual-basis-nonviolent-communication …

   Expand
3. Guy Nachimson ‏@guynachimson19 May

   @flowchainsensei thx for the pointer. Not sure I relate to that as I did at #agileil13, but I'll give it a shot

   Expand
4. Bob Marshall ‏@flowchainsensei19 May

   @guynachimson I’ll take it under advisement for a future blog post :)

   Expand
5. 
   

   Guy Nachimson ‏@guynachimson19 May

   @flowchainsensei I'll stay tuned :)

Guess what?
Today, Bob posted: Hyper-joyful, quoting Ackoff, Seligman, Deming and Rosenberg to support his debate with the prevailing assumption that work isn't supposed to be fun. It's a call for focusing on Joy at work rather than productivity. A joyful environment underlies hyper-productive teams.
Culture trumps Process, right?

Agile Israel 2013

I thought to start blogging with a totally different post, but attending this conference was a good opportunity to jump right in, without a perfect first post :) 

I think this is going to fuel some future posts.

I've been attending AgileSparks conferences and courses in the past few years. There's always something new and thought provoking. Here are my initial notes from this year's event.

Over all, attendance was impressive, which caused some logistic difficulties (like missing chairs and some mess around lunch). Being of the twitting kind, lack of WIFI was a fail (especially blocking international participants from twitting), though I know vendors set ridiculously high price tags for this.

There was a rich, 4 track program, so obviously I had some hard choices to make.. here are my highlights.

Bob Marshall (@flowchainsensei, blog) gave the opening keynote, introducing rightshifting. The talk itself had a great start - I personally loved his guiding principle of "Joy for all". In my workplace we have the official "core values" (Trust, Win mentality, Communication, Responsibility and Innovation) and I often half jokingly suggest "Fun" is missing or should just replace the others... However, as the talk developed and time ran out, a long list of 18 approaches to organizational cultural transformation went by so fast with no context or advice which sort of felt the whole keynote didn't satisfy my expectation of a focused, practical, concept. 

During the talk, and later in a dedicated session, Bob introduced Nonviolent Communication (NVC). This was interesting, and correlated very strongly to me with the work of Christopher Avery on personal Responsibility and it's application to support and drive organizational change.  

Danko (@DankoAgile) talked about Planning - he can definitely hold a crowd, but the most of it was targeted for beginners. Still, some aspects to consider improving, and some hints to consider as potential future state such as blitz planning. I was missing the question - do you really need those estimates (Gil Broza got to it later..) and the topic of understanding the stories and preparing for the sprint was left out. 

While I don't think he mentioned it, for more on these hinted new ideas he wrote the free book AdvanScrum.

Naresh Jain (@nashjain, who is) talked about dealing with uncertainty in a complex adaptive world. The focus was to highlight how biased our minds are towards (false sense of) certainty, and overview of Dave Snowden's Cynefin model. He's suggesting certainty is not an option and we'd better get used to being more much empirical about things. For example, copying a process is like copying a haircut - you might end up looking stupid. Some parts very amusingly delivered - well done.

To hear Naresh, I had to skip Yuval Yeret's (@yuvalyeret) talk, which he blogged about here. Sounds like lot's of good stuff... Alas, the road not taken.

Rafi Bryl from SAP introduced Design Thinking and Lean Canvas. He compared D.T. with Lean, explained the key parts and origin of D.T, and the concept and application of lean canvas. An important take away is that the real innovation lies not in a product/technology but in the overall business model (great examples with Xerox and Sony betamax). Good intro to topics partially new for me.

Tony Gilling from Rally covered SAFe as a framework to scale agile. On one hand it seems quite straight forward, on the other hand could be too rigid for various organizations... Sorry to say this, but it felt like promoting consulting services rather than teaching something new.

Closing keynote by Gil Broza (@gilbroza) shared 10 ways (or, lessons) to put people before process. To be precise: Individuals and Interactions over Processes and Tools, as the intentionally first value in the Agile Manifesto. Gil covered patterns and anti-patterns with potential outcomes of following each. Once the slides are published, I recommend taking a good look for any manager - read it slowly, and check yourselves.

Later a small group had some good discussions in the Lean Coffee session. One of the participants asked:

"Is Agile going soft?"

He was referring to the relatively many sessions dealing with the "soft skills"/human aspects, rather than tools, metrics, etc. Just look at the keynote speakers: Gil, author of "Human side of Agile" and Bob with the soft-as-soft-gets nonviolent communication. I personally liked this focus a lot, as I strongly relate to the underlying ethics agile is built upon as personal motivation.

If you attended other sessions or can add to those I commented on, you are welcome to share your thoughts in the comments section.