Kicking the Sitting Habit @ACCUS 2015

Uncategorized

Sitting1Attending the Agile Coach Camp in Washington, DC on August 1-2, 2015 – I offered to serve as a scribe in one of the sessions to which I found out that AgileLIB only allows for 1000 character posts – as can be imagined, I had a bit more to say.  Read below to find out more about a discussion I attended (and took notes in) regarding how to inject more physical activity and movement into agile teams – for more information on the sessions held at “Agile Coach Camp 2015 DC” check out AgileLIB at: http://agilelib.net/?event=accus15

 

 

“Kicking the Sitting Habit”

Sitting2At the Agile Coach Camp in Washington, DC – Leslie Zucker (www.lesliezucker.com) convened a session entitled “Who wants to kick the sitting habit?” focusing specifically on how to inject more physical activity into the agile community.  To her credit, Leslie had session participants moving around, stretching and exercising during a Lean Coffee style conversation to drill into some of the topics related to this subject.  

 

 

The group dove into discussing causes and mitigations for what to do about “People being bored at work” – there was consensus amongst the group that “Sitting Wears You Out”.  The group then brainstormed a variety of things that you (or a team) could do to overcome boredom and increase engagement / energy in one’s work.  Ideas shared included:Sitting3

  • Creating a team push-up board (everyone does 100 push-ups throughout the day)
  • Using a FitBit or Apple Watch to track fitness at the person or team level
  • Working at a standing desk
  • Do something to exercise your brain at work (mind-stimulating work)
  • Provide sporting goods for employee / team fun (Impromptu Volleyball / Soccer matches)
  • Inject/Demonstrate physical movement into work activities (Use a Pomodoro Timer, every time the timer goes off, stand up, walk around and stretch something out – use a stretching chart to work your way through the body throughout the day).

 

Next the group focused on things group members felt they could do to “inspire” movement amongst their team members and colleagues:Sitting4

  • Lead by example (don’t ask people to be active, model active work behavior yourself)
  • Get out of the office and go for a walk (retrospective outside in the park)
  • “Walking Meeting” or even better how about a “Running Meeting” (walk or run while you talk)
  • Find out what kinds of activities / movement people like so you can invite them
  • Sponsor/Organize/Support an in-office corporate fitness program
  • Maintain the safety of the environment and/or activities/exercises introduced into it
  • The nature of the movement should be focused on “activity” rather than “exercise”
  • Behavior to inject movement into a work environment / team cannot be mandated (HR/EoE/ADA concerns) – people can be invited to move but should be respected if they decline
  • Tell stories about the benefits of movement – “I feel great today because I climbed 20 flights of stairs to get up here”
  • Track the Happiness Metric and see if injecting movement into the workplace or a team improvement is (Hypothesis is it will)
  • Provide Healthy Snacks
  • Join the Movement Movement – contact Leslie @DCWorkshopWoman for more info

Thanks again to Leslie for convening the session and getting us moving around right after lunch to burn a few calories and avoid the urge for an afternoon nap at Agile Coach Camp DC 2015.

Bonus Round – A few more insights for attending Agile2015

Uncategorized,

I was asked at Agile Coach Camp in DC (prior to Agile2015) if I had any “runner up” items for my Top 10 list of insights for maximizing your conference experience.  It turns out I did, so for fun here they are (you can let me know if any of these should have been on the original list):

 

What to do if you forgot your business cards (or run out or want to save them or a tree)

I predict that not too long after Paul Hammond welcomes everyone to Agile2015, he will probably remind everyone to “Wear your badges” (necessary for security & access control) – this is good as snapping a quick badge photo is a quick way to capture the name of someone that you’d like to follow up with – once you have a badge photo, you can look your new colleague on LinkedIn or Twitter.  Think of all the trees you can help save!

 

Please Please Please take a moment to leave session feedback

One of the greatest value that presenters (either on the formal program or in OpenJam) receive from participation and sharing ideas at the conference is feedback to help them improve their future sessions.  While you can give direct feedback to the presenters (some may include a feedback door or wall in their session and ask for input), you’ll also have an option to leave feedback for any session you attend via the online conference schedule (use your mobile device or access via the web).  In advance, all of the presenters will thank you, as it helps them improve.

 

Thank (maybe even hug) all the volunteers you see (and don’t see too)

The agile conference is made possible largely by the efforts of volunteers who are there to assist presenters and handle all of the behind the scenes logistical tasks.  The volunteers are easy to find (usually wearing a nice bright colored T-shirt – at the time of writing, I don’t what the color is this year) and they will answer questions you may have.  Without volunteers donating their time to support the planning and execution of the conference, the event would not be feasible without significant additional cost.  Also ask around if anyone you meet was a “Submission Coach” or “Track Reviewer” – these are people that donated their time in late 2014 thru early 2015 to help presenters improve their sessions, and then gave input to help select quality sessions to create the conference program – please thank all of these people for their efforts!

 

Be transparent about your needs

I’ll forgo the various metaphors between the complexity of planning, building, integrating and releasing a conference and running an agile release train (trust me they exist), but executing a 5-day conference with 200+ sessions is a complex task and some things are bound to go wrong – sessions run out of handouts, rooms become over crowded, etc.  Here’s a tip, if you end up missing a handout or can’t make it into a crowded session, connect with the presenter (Twitter works best for most) and more than likely they can accommodate your need – handouts can be sent electronically and each year, I know there are always several “popular” session for which the presenters offer “encore” presentations in the OpenJam if requested.  Control your destiny – make your need / request / idea known and be prepared to be surprised.

 

Use the Law of Two Feet

From “Open Space Technology” the Law of Two Feet, provides the freedom to people that if they are attending a discussion or session for which they are not receiving value, you are empowered to leave and go elsewhere to find value.  While Agile2015 is not a full open space event (it does have an Open Space component via OpenJam), I would suggest that the Law of Two feet is in effect.  If you head into a session and it quickly pivots into something that you aren’t interested in, don’t be afraid to exercise your option to leave and head to another session where you might receive greater value.  You are responsible for maximizing the value you get out of the time you invest to attend a lengthy conference such as Agile2015 so you should exercise your empowerment to maximize your return from time invested (ROTI).

 

Try Out The “Surprise Rule”

I learned this trick from a colleague attending conferences in another industry – since Agile2015 is a week-long conference, give yourself a treat at least once or twice and go to a session that has NOTHING to do with what your normally do (exposing yourself to new ideas so as to perhaps learn about a future career pivot) – you’ll know if you’re picking a good session since you may even feel a bit anxious walking into the room (how on earth am I going to relate to anything that is discussed / presented in this session) – example: if you’re a scrum master, go to a session about coding and refactoring (hands on keyboard) – if you despise budgets, financials and Enterprise Governance, go to a session on the Portfolio track – specific for this year, if you work at a startup or a private-sector organization, go to a session on the Government track.  Sometimes hearing information and ideas that is tangentially related to what you normally do will give you greater insights on how to improve vs. listening to ideas in your current area of focus / expertise.

 

Don’t be afraid of friendly agile people

Conference attendees have achieved nearly 100% occupancy for all the hotels in National Harbor for the entire week so you will be surrounded by community members – I dare say that we’re a highly inclusive and welcoming group, so don’t be shy to make friends and strike up a conversation with the person sitting next to you at the bar or at a restaurant.  Many resort to Twitter to look for people who are “hanging out” but from personal experience the old fashion “just show up” techniques work just as well.

 

Silence is Golden

I’ll describe the annual Agile Alliance conference as a “loud” conference – first, there’s a ton of people attending (SOLD OUT), there’s lots of chatter between sessions, dialogue during sessions, and of course after hours socialization, and even BEFORE hours socialization for the Lean Coffee crew (which everyone should check out).  Believe it or not, the physiology of your brain determines your tolerance for prolonged exposure to “loud” (yet non-deafening – less than 90 dB) environments.  Your brain will appreciate some quiet time and some people need more of this than others, so don’t be afraid to seek out some quiet time – your choice to refrain from conversations (or even socialization) will be respected.

 

Go Outside

This insight is of particular importance for people staying at the Gaylord – with all of the conference sessions behind held on premise this year (including the party), it is possible to enter the Gaylord on Sunday and NOT exit the building until Friday.  This is not recommended!  Fresh air rejuvenates your brain, and taking a break to go for a walk outside (along the river) will provide some of the “Silence” mentioned above to balance against the overall “loud” environment of the conference.

 

Twitter is useful even if you don’t post – #agile2015

While not everyone is a frequent poster on Twitter (nor do you have to be), many attendees and presenters at Agile2015 use Twitter extensively, it’s highly recommended and useful to follow the #agile2015 hashtag.  You don’t have to have a Twitter ID to follow along, and you can even just use a browser without needing to install a Twitter app (just go to www.twitter.com/hashtag/agile2015) – this is your best stream for up to date information about what’s going on and late breaking ideas or sessions that you might want to check out.

 

That’s all for now – Enjoy the journey!

10 Insights for Attending Agile2015

Uncategorized,

Recently I shared some insights with a few colleagues attending the annual Agile Alliance conference for the first time – I picked up most of these myself attending prior Alliance events.  The 2015 conference is coming up in Washington, DC – Agile2015 (August 3 thru 7, 2015) – the group mentioned these were helpful so I thought I would share them with anyone else who was interested.

 

The conference organizers do present a few first-timer orientation sessions (Sunday evening, 8/2 and Monday 8/3), which I’m sure hit a few of these things, but here’s my Top-10 list of things other than attending the regular 75 minute sessions at the conference:

 

#10 – Lean Coffee in the morning

If you’ve never tried Lean Coffee don’t miss your chance to experience it at Agile2015 – Look for the time and meeting location to be announced on Twitter with #agile2015.  Yes, you do have to wake up a little bit earlier, but you’ll get to meet people and discuss a variety of agile topics (and there’s coffee there to help you wake up).  Lean coffee is a small group discussion which is focused on the questions & topics participants share by writing on Post-Its – listeners are welcome, but anyone sitting at a table has an opportunity to contribute.

 

#9 – Check out Open Jam

Think about checking out or sharing an Open Jam session – Open Jam allows anyone to convene or present a session on a topic of their choice – all you have to do is attend the morning “Huddle” (see the program for time and location) announce your topic, sign up for a space and time on the board, and then be present to convene your session (very much like an Open Space).  In Open Jam, you’ll find sessions that sometimes focus on emerging topics, and it’s pretty common that a “rough” idea you see at Open Jam this year, may return in a more “polished” form at Agile 2016.

 

#8 – Stop by the Coaching Clinic

If you currently have a coaching problem, puzzle or just looking for coaching insights, the Scrum Alliance is hosting a Coaching Clinic that runs throughout the conference.  You can sign up in advance for a short session with another coach to discuss and share ideas – they also typically have capacity for walk-ups, although preference is given for people that sign up in advance.  Don’t miss your chance to get FREE advice and coaching from experts in the field.

 

#7 – Great Keynotes

Don’t miss the Keynotes at Agile2015

  • Monday: Luke Hohmann talks about using games to solve “SuperProblems” #AWESOME
  • Wednesday: Jessie Shternshus will have us doing Improv (high probability of a flash mob) #FUN
  • Friday: Jim Tamm closes out Agile2015 challenging us to look inside ourselves to enable better collaboration #REFLECTION

 

#6 – Lightning Talk Sessions

Scattered throughout the program there are Lightning Talk sessions on specific topic areas.  Lightning talks are quick 3-7 minute presentations (there are a couple different formats the presenters can choose from ) – so if you are looking for a variety ideas on a topic like “People” or “Process at Scale” – you’ll walk away from a lightning talk session with 6+ new ideas on that topic all presented real quickly.

 

#5 – Stalwarts

Also scattered throughout the program, the Alliance invites well-known members of the community (Dean Leffingwell, Ron Jeffries, etc) to convene a session to answer questions submitted by the audience – this is your chance to submit a question and have it answered by a well-known expert in the field.  A moderator facilitates the Q&A and works to manage time to address as many questions as possible in the time allotted.

 

#4 – Agile Alliance Annual Membership Meeting

Want to learn more about what the Agile Alliance does in addition to the conference, and how to get involved, run for the board, volunteer, etc – attend the annual membership meeting late Wednesday afternoon.  There’s typically food and drinks provided for those who attend.

 

#3 – Evening Entertainment Rundown

Here’s the summary of the evening activities, where you’ll be able to redeem your coveted drink tickets for fun beverages:

  • Sunday evening – Very Brief “Welcome” reception (1 hour)
  • Monday evening – Ice Breaker Reception – held in the Expo Hall with food & beverages available – also some kind of entertainment too.
  • Tuesday evening – The Alliance organizes a “Dinner with Agile Friends” event – sign up to go to dinner with people from the conference at a restaurant located in the resort (great option of “evening Lean Coffee” for those that don’t want to get up early) – Tuesday is also typically VENDOR party night – some events are on-site, some events are off-site, and at least one is on a boat this year (anyone renting a bridge that the boat can go under – if you were in Nashville you might remember).
  • Wednesday evening – Sponsor Reception – get stamps from the vendors in the Expo hall on the card in your program, then enter it in the drawing for a prize – food & drinks available – also, please remember to PRINT your name on your card BEFORE you submit it, last few years, they always pull out a few cards without names, so don’t miss your chance to win a prize.
  • Thursday evening – Conference Party – this year it’s super-hero themed and held on premise – food and beverages available.

 

#2 – Make A Post It Reflection for each session you attend

The Agile conference is like a marathon – it’s 5 days long, and only happens once a year (it can be overwhelming to some) – why does that last statement make me think of something that Winston Royce used to describe software development in a 1970 whitepaper which I seem to recall was the antithesis of agile.  Regardless, maximize what you get out of the conference by taking a minute to summarize 1 or 2 things on a Post-It note for each session you attend – you’ll find the act of writing a few quick notes on a Post-It helps your brain digest all of the information you’ll learn while attending.  Your brain (and boss) will thank you when you leave DC and want to share what you learned, you’ll be able to pull your 20+ Post-it notes (1 or 2 for each session you attend) and tell them about your experience, and/or take a picture and say “here’s my conference report”, if by chance you have to submit one of those.

 

#1 – Take a break

Related to the “marathon”, I have to thank David Anderson for this one – the 2015 Lean Kanban North America conference was held in Miami Beach on the beach – each afternoon David Anderson gave everyone a 3 hour break and told us to go to beach (he even gave us Flip-Flops).  Now we don’t have a beach in DC, but if you do take a “break” sometime you’ll find yourself able to attend sessions refreshed and ready to learn & your brain will thank you as well.

 
There you go, 10 Insights for Agile2015 – enjoy!

Live from New York, “It’s 30+ metrics for agile & Scrum teams” . . .

Uncategorized, , , , ,

BASDNYCIn June 2015, I had an opportunity to share insights on advanced metrics for agile and Scrum teams at Big Apple Scrum Day in New York City.  The metrics I highlighted were all aimed at allowing teams to better assess the impact of changes and improvements they put in place while creating and delivering software.  My motivation behind sharing additional metrics for teams was based upon positive experiences where I have observed that having data from metrics improves team self management as teams can make decisions based on upon fact rather than opinion.

The presentation included a disclaimer, whereby teams need not track all 30+ metrics highlighted in the presentation, but rather teams should track sufficient metrics to have a full understanding of their process.  Since there is a cost to gather and review data for each metric, tracking 30+ metrics on a team may be a bit too much – my intent in the presentation was to show options and ideas on what you can measure on a team / software development project that those attending may not have thought about before.  Since all teams are different (since they are composed of different people and have different areas in which they are working to improve), it can be expected that different teams will track different metrics and this is OK.  Moreover, a team may start tracking a new metric to assess a specific challenge or improvement; however, once the team improves in that area, they may find it no longer necessary to track that metric – the metrics a team tracks should change over time.

In the presentation I highlighted 5 different categories of agile / Scrum metrics and recommended that teams track a few metrics across each of the following 5 categories to be able to assess software development, delivery and continuous improvement activities:

BASDNYC2

  • Process Health Metrics – Assess day-to-day delivery team activities & evaluate process changes
  • Release Metrics – Direct focus to identify impediments to continuous delivery
  • Product Development Metrics – Align product features to user needs
  • Technical / Code Metrics – Determine quality of implementation and architecture
  • People / Team Metrics – Promote sustainable pace and team engagement

 

While highlighting various metrics across these 5 categories, several questions did come up which generated insights not included in the presentation and reference materials below:

Someone asked – “How can you figure out Business Value Points for the items in your backlog?” – Two activities / games I recommended and have used:

Both of these games allow for business value to be assigned to the items in your backlog in a collaborative manner.

Someone asked – “How do you get test coverage data?” – The best way to do this is to setup your continuous integration (build) server (Jenkins or equivalent) with the appropriate plug-ins for the language that you are coding in – as an example go the Jenkins wiki on “Build Reports” (https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Buildreports) and search for “coverage” and you’ll see a variety of plug-ins you can integrate with Jenkins to capture test coverage for every build.

Someone asked – “How do you collect Happiness metric data?” – Two techniques I recommended and have used:

  • For co-located teams, put a shoe box in the team area along with a supply of Red, Yellow and Green note cards – at the end of each day, team members put a card into the box to capture their happiness for the day (Green = Happy; Red = Not Happy; Yellow = Everything else), then open the box, review its contents, and discuss ideas/insights at your team retrospective.  With this technique, some teams find it interesting to write the date on each colored note card as it is submitted into the box – this will allow you to correlate happiness with specific days during a sprint.
  • For distributed teams, you can achieve the same outcome by creating an online survey (SurveyMonkey) or Google Form and allow people to enter their happiness for the day – then create a graph of the data for discussion during your retrospective.

Something to add – Additional insights on cycle time – When we talked about cycle time we focused mainly on capturing the time required to complete development and testing of a story; however, many groups I have worked with found value in measuring the cycle time required to create and refine stories so they are ready for development.  I have worked with several teams that track stories as they are being created on a separate board so they can collect the cycle time of story writing & refinement.  Reviewing the cycle time of the activities to write / review stories has allowed those groups to identify impediments that were slowing down story writing activities.

 

Thanks to the organizers of Big Apple Scrum Day for the opportunity to insights on advanced metrics with conference attendees.

 

Presentation Materials

Check out the links below to download the presentation and metrics reference sheet from Big Apple Scrum Day (June 2015):

Presentation Slides:

Presentation Handout – Metrics Reference Sheet:

“Agile Office Hours” – Experiment Outcomes . . .

Uncategorized

Yikes, it’s been over a year since I had a chance to update TheAgileFactor – thanks to all those who sent out search parties to find me, thinking that something went awfully wrong during the “Office Hours” experiment.

That said, “Agile Office Hours” was a great experiment that provided value and generated some learnings for which I wanted to share the outcomes.

Overall outcome

Did “office hours” work?

YES – multiple people showed up, they all asked questions, and shared that the information shared did provide value – a few even came back for multiple sessions.  

I also received questions from those who were not able to attend inquiring what topics were discussed.  This served as evidence that there was interest in the discussion & learning beyond those who were able to attend.  Also since posting the experiment, I’ve heard from a few other agile coaches that they have successfully done this (specifically Richard Kasperowski – www.kasperowski.com – who with me is volunteering to organize the AgileGames 2015 conference in Boston – www.agilegamesnewengland.com).  I also found out that many organizations that have an agile office (to support all their teams using agile methods) have adopted this strategy for ongoing support & coaching.

What was challenging

  • Supply & Demand – much like in college, specific events seemed to trigger an increase in the demand for agile office hours (think about people waiting to go get help until just before the exam) – some implementation challenges were experienced as people would show up for office hours wanting to ask a specific question, but then would end up having to wait until their question came up in the discussion queue – “Lean Coffee” was a great format to facilitate time-boxed coaching chats – questions / topics were collected from those present and then prioritized; however, this system can be challenging if you have a specific question and you need to listen to the rest of the topics for your turn to come up.  Of course, this listening wasn’t always bad as people did report learning and getting ideas from the discussion while they were waiting for their turn.
  • Sharing information from office hours with the whole-team – I experienced a trend where two or three team members would come to office hours with a question or puzzle specific to their team – we’d have a great discussion during office hours, but then that would setup a request to have a meeting / coaching session with their full team to relay the same information to everyone.  A few people talked about bringing their entire team to office hours, but that never happened.
  • People wanting a “magic pill” vs. guidance to enable their own learning & experiments – Most of the people that came office hours were looking for guidance or suggestions based upon specific challenges.  This type of advice proved hard to provide since I didn’t have a strong knowledge of team activities, and / or metrics for most of the team’s requesting assistance.  Rather I spent a lot of time helping teams to define experiments with indicators so as to measure their impact and effectiveness.  Initially, there was some question about whether this type of information was useful, since it wasn’t prescriptive (aka: this is your problem, here’s what you should do); however, people that implemented experiments that were defined during office hours reported improvements and moreover also demonstrated the ability to define future experiments and indicators without the need to attend an office hours session.

Recommendations

If you’re a coach and you haven’t tried holding office hours, definitely give it a try – you will most certainly get questions, challenges and puzzles that will make you think – the challenge is not responding by telling teams/people what to do but rather giving them advice so they are empowered to learn and identify what works best within their context.

I would recommend complementing face-to-face sessions with the ability to provide assistance online as well.  Myself and several colleagues had good luck experimenting with an internal IRC/chat channel for “agility” to improve our office hours offering – my organization did this using Slack (www.slack.com) or you could use a tool like Basecamp and just create a “coaching” project that everyone is on (www.basecamp.com).  The chat channel allowed for people to ask questions and share ideas outside of office hours.  Quick questions could be addressed online immediately, and face-to-face sessions could be scheduled for more in-depth discussions with the correct people.  Perhaps most important, responses in the chat channel helped to identify others interested in coaching (since everyone was empowered to share ideas and suggestions based on needs / questions posted) and all information was transparent making the channel a good place to search for recent references on agile topics vs. having to track down an agile coach.  The online channel also made coaching help available to those working in different locations.

Agile coaching via “office hours” . . .

Uncategorized, , , ,

I am getting ready to try a coaching experiment and see what happens when we take a trip back to college and see if the idea of “office hours” can be used to provide effective agile coaching for teams.  Since this is an experiment (and I have no idea what will happen), I figured I would write something about it first, then I can write a recap about what actually happens.  Of course no cheating is in play, where I alter my hypothesis knowing what the outcome is.  For reference, my first office hours session will be on Tuesday, 1/21/2014 (so this post on 1/20/2014 is before the truth is known).

A bit of context:

  • Office Hours (from college) is a scheduled time when professors or teaching staff make themselves available to answer questions, review assignments, go over problems on sample exams, etc – basically, if you need help, you can go to your professor’s office at a set time and receive assistance – assistance is typically provided in a first-come, first-served manner – although good professors and teaching staff have been known to do something to survey if there are common questions when there is a large group, for which discussion or review topics may be prioritized.  As a former teaching assistant in college myself, I will propose that office hours (in the collegiate sense) are event-driven – at the beginning of the semester, nobody shows up; however, by the end of the semester just before the final exam, the line can be all the way down the hall.
  • In my professional context, Daniel Pink (in “Drive”) mentioned the idea of hosting office hours as one of his 3 steps towards giving up control – rather than summoning people to come and meet with you, provide an open door and allow those who are interested or are in need to seek out guidance.  I like this parallel for coaching self-managing agile teams – rather than management assigning a coach to work with a team because management thinks that a team is struggling, make a coach available and then allow teams to decide if they want or need to seek out advice to help them improve.
  • At various agile conferences, I have been to a variety of coaching clinics and been impressed at the quality of discussion and information that can be obtained in a short coaching session (either small group or 1-on-1) – suggestions of experiments to try, or perhaps a metric you can use to measure the effectiveness of your own experiments – bottom line: effective coaching and guidance can be provided without a complete understanding of one’s context.
  • In terms of environment (since that’s a component of the experiment), I work in a development office that has a few dozen projects and development teams – not every team has easy access to a coach – I have a strong suspicion that a few folks are going to show up, but I don’t think that the entire office will show up (if that happens, we will have a problem) – then again when I was a teaching assistant for a Computer Science class with 200+ students in it, office hours rarely had more than 20 visitors (even right before final exams).

A few motivations:

  • “Agile office hours” is an attempt to make coaching available to any and all interested teams, knowing that not all teams have easy access to a coach.  It is unknown how effective the information and guidance provided will be since it will be based on a very limited set of information (the questions and information people bring with them to office hours) and the complexity of work being done in our office is much greater than that of a course curriculum grounded in a common syllabus that is well understood by the professor and teaching staff.  I think some topics like metrics to measure team risks and/or progress could be common topics that will be easy and effective to discuss in a mixed group; however, challenges related to specific teams, and coaching on how to handle conflicts of opinions within teams will be more challenging in an open group setting.
  • My intent with “agile office hours” is two-fold seeking to provide some benefits to both myself and also to those requesting guidance.  I get a lot of questions and requests for coaching help around the office – I receive these requests in varied and ad-hoc manners (some spoken, some Email, etc).  From “lean systems”, I’m hoping agile office hours will allow me to better control the inputs to my coaching queue, as it encourages inputs to the system at a time when I will be able to respond immediately.  I also hope that office hours provides better customer service to those seeking assistance – folks who come to office hours can receive information and guidance right away, vs. sending me an Email and having to wait for me to see it and respond (which can take a day or two – I get too many Emails).

How things will work – I hope:

  • Folks interested in assistance (with current challenges) will show up – office hours are focused time to discuss challenges and how to overcome them within team.   I hope that others who come to office hours for guidance may also be able to provide some guidance to those in attendance.
  • We will have a quorum, but not a crowd (I don’t have that many chairs and/or space) – if we have a bit of a crowd, I suspect we’ll use a Lean Coffee board to identify questions and then use dot voting to find the highest priority topics to focus discussion and time on the topics that provide the most value to the group.
  • If we get into a specific discussion for a project or team, we’ll table that discussion from office hours (unless those are the only folks at office hours), and rather setup a focused coaching session with that team for a deep dive on the issue.  I also hope that full teams don’t come to office hours (again, I don’t have that many chairs) but rather send a representative or two for a preliminary discussion to get a few initial ideas and which in turn perhaps sets up a focused team coaching session (where the whole team can participate without the chair restriction).
  •  I’m hoping that office hours could work well with retrospective outputs – perhaps a team had a retro and identified an issue or challenge – office hours could be used to help brainstorm an experiment to work to overcome the challenge, ideally so there is something to reflect on at the next retro.
  • Most important, relevant and useful information is provided to those that have questions allowing them to improve.

That’s enough ideas and hypotheses to get started – next we’ll see what actually happens (to be continued . . .)

Southwest Airlines Seating – Effective localized governance & lean systems thinking for self-managing agile teams

Uncategorized, , , , , , ,

As I was recently reflecting on my activities in 2013, I shared a metaphor that I experienced frequently during the last year and several have commented is perhaps one of the better examples of effective localized governance in action (applicable to self-managing teams) – imagine an effective system where the organization has defined system-level boundaries allowing for participants to make decisions at the last responsible moment to maximize customer value based upon the most accurate and relevant data at the time of the decision – could the Southwest Airlines system for open seating provide some parallels to emulate within the leadership of self-managing agile & lean teams? I think so.

Residing in St. Louis, MO and traveling extensively throughout 2013, I found myself frequently choosing between Southwest and other carriers mainly due to available flights and airfare (working to optimize that travel budget), this provided an interesting opportunity to examine the different levels of service and systems employed by different airlines, for which Southwest has certainly embraced many elements of lean thinking.

Southwest’s lean and self-governing approach

Let’s examine the Southwest experience from a systems perspective (and to familiarize those that might not have experienced it personally).  Southwest offers a single class of service (open seating) – they minimally enforce the system-level boundaries in accordance with the seating capacity of their aircraft and FAA policies (all passengers must sit in a seat, you can’t sell a ticket to sit in the lavatory).  Southwest’s system assumes a minimalist approach as they only govern the number of tickets issued per flight and they cannot issue more than 143 or 175 tickets per flight (based on the type of aircraft used).  Southwest’s system does not include any additional complexity (or associated costs) to assign seats ahead of time, rather this complexity is delegated to individual passengers as they board their flight and can pick whichever seat they’d like and isn’t already taken.  Southwest’s system empowers passengers to select whatever seat they would like based upon each passenger’s unique and complicated preferences (which perhaps Southwest has realized are far too complicated to track in any database or CRM tool).  Passengers are enabled to make decisions seeking to maximize their personal utility at the last responsible moment based upon the other unique factors (the other passengers) that happen to be on your flight with you.  Since Southwest chooses to not involve itself in the complexity of the seating assignment process, customers are observed to take greater personal responsibility for their seating decisions – they can’t complain to the flight crew that they don’t like the seat they were issued and demand to be reseated, rather Southwest passengers make the best decision they can by understanding and accepting the well-defined constraints of the system.

Can increased complexity provide greater value?

Other airlines opt for a more complicated, costly and rigid system to address the same basic problem of airline seating – many have opted to layer on additional complexity to their systems in an attempt to offer more personalized services.  It is up for debate about how personalized the services are and whether or not they provide better customer value.  Beyond selling tickets in accordance with aircraft capacity and adhering to FAA regulations, complexity and costs are increased as options are added allowing customers to choose their seats ahead of time.  Before we even get to value, this increases complexity and cost – think about all the complicated software that needs to be deployed and supported to allow passengers to choose their seats (Southwest avoids the need to run and maintain this additional software) – think about all the inbound calls airlines receive in their call centers to handle seat requests and/or changes (Southwest cuts down on their call center volume, which lowers costs, by simply not having to deal with seating requests).  As for opting to increase the complexity of the system for the purpose of providing greater customer value, I hypothesize that greater value isn’t always achieved.  Let’s consider a flight where you are able to reserve your seat in advance (of course, you rarely know who will be sitting next to you), only to find out when you board the plane, that you’re sitting next to someone who perhaps you’d rather not be.  And of course as luck would have it, that intriguing and attractive person you were talking to in the gate area before boarding that you wouldn’t mind continuing to talk to for the next few hours happens to have been assigned to sit by someone else.  In this instance, the customer received minimal additional value by being able to choose their seat in advance.  Even worse, suppose you attempt to change your assigned seat (Southwest style) and self-negotiate an opportunity to sit next to your new intriguing friend from the gate area – if you’re successful, all of the costs associated with providing the ability for you to select a seat ahead of time become pure waste.

What about “Respect for People”?

Lean thinking says that by not troubling your customers, you show respect for people – designing systems that promote respect for people is a foundational principle for successful lean systems – I’ll propose Southwest has an advantage here.  Consider this example: try booking six seats for an unexpected family trip with 3 weeks of lead time – since you are traveling as a family with small children, it would be nice if you could all sit together (plus I’m sure someone traveling on business really wants to sit next to my 4 year old).  On Southwest, you are able to book your tickets on your desired flight, and then show up at the airport where Southwest provides a specific time for family boarding (between the A’s and B’s) that has been strategically placed within the boarding process seeking to respect all of the different groups of people that fly on Southwest.  Family boarding occurs after the A-group, allowing those A-group frequent travelers to claim the coveted seat that they feel they have earned, meanwhile families are guided to board the plane at a time when there are still plenty of seats together so their desire to sit together can be easily accommodated without additional hassles or fees – family boarding is a standard part of the system that was implemented at minimal cost and without complicated software or processes to support it.  On other airlines (if you try this experiment, I have), when you book multiple tickets with a short lead time, you’ll find that you may have to pay premium seat upgrade fees to be able to reserve seats together, and even if you have elite status (where the seat upgrade fees are waived), single travelers typically reserve seats with ‘empty’ seats around them, so good luck trying to find a block of seats together.  A 30-minute call to the customer support center (costly to both you and the airline) may result in the agent being able to work some magic and find seats together – regardless having to wait on hold to attempt to resolve a seemingly simple request may make some question just how much the system “respects” them as customers.

Negotiating with the system vs. with the people

Perhaps the most interesting observation from my travels of 2013 is how Southwest’s strict adherence to only governing the system level boundaries (putting up to 143 or 175 passengers on each plane) promotes more effective self-governance and respect amongst its passengers.  If you are traveling on an airline with an assigned seat, ask fellow passengers if you can swap seats with someone to sit next to a colleague or family member.  You might get lucky and get a yes, but more than likely you’ll get a “No” since many feel entitled to sit in the seat they reserved.  Furthermore by the system governing seating assignments, passengers exhibit a preference to negotiate with the system rather than with their fellow passengers who actually can provide better data to make more effective and relevant decisions.  On Southwest, since the system is not involved in seating assignments, passengers are more open to negotiate with the other actors in the environment (their fellow passengers) and are willing to accommodate and respect the needs of their fellow travelers – those seat swaps to accommodate requests to sit with family members, colleagues or those attractive and intriguing new friends from the gate area are more frequently respected and accommodated.

Disclaimer

Before anyone goes there, this isn’t intended to be a slam on any airline, nor is it a glorification of Southwest – Southwest has definitely adopted some elements of lean systems and localized governance that are interesting to discuss for application in other contexts (self managing software development teams).  Southwest offers a unique and high quality travel product, as do other airlines, and while I do my fair share of travel on Southwest, I’ll opt for first class with Mimosas and other tasty beverages for long-haul flights on any day of the week.

Takeaway for managers/sponsors of agile teams

The takeaway from this metaphor for those sponsoring or managing agile development teams is to focus on defining the minimal number of constraints that form the boundary within which teams can self-manage.  Work to make those constraints as simple and explicit as possible (the plane has 143 or 175 seats, everyone must sit in one of them), then trust in and provide autonomy to your agile development teams and allow them to figure the rest out without your direct involvement.  If self-managing team members struggle to reach consensus or resolve internal conflicts, perhaps you can point out where a few of the open seats are on the plane, but ultimately ensure that you allow the team members to decide where they want to sit.

4 Estimates & a Gantt Chart – The “Planning Party” Response . . .

Uncategorized

In established political fashion, I must now provide a more sensible “Planning Party response” to the rhetoric espoused by Amos (@adkron) regarding the “appropriate amount of planning” discussed during ThisAgileLife Episode 25 “4 Estimates and a Gantt Chart Ago”.

During the episode, my colleague Amos alleged that 4 months of planning to establish a new blog site (www.theagilefactor.com) was unacceptable, and that much of the planning and consideration that I put into launching the site was unwarranted.  Furthermore I should have been able to bring the site online in less than 4 months, and some may assume from the amateur-style debate rhetoric during Episode 25 that it took me 4 months of focused work to “think about what I wanted to do, then setup WordPress, and finally post something” – let me set the record straight on a few items:

  • Since I have many other obligations and activities going on, working to bring the site online and create the initial content was not my top priority throughout the 4 month period – I focused on it during my extremely limited spare time.  More accurate use of a technique like “Personal Kanban” or “Pomodoro” so as to identify and more carefully track key items (along with the many other items competing for my very limited spare time) may have reduced the time needed to launch the blog as I would have had less total work in progress.  Reducing my work-in-progress and prioritizing completion of the items related to launching the blog would have improved flow.
  • As for Amos’ claim that 4 months from envisioning to delivery was unacceptable – Amos has no solid value data to support this.  Ideally release of capabilities within agile development projects should be prioritized to maximize business value (ideally at the feature, not at the project level); however, in this case, my new blog is something that I’m doing on the side and there wasn’t any significant different in business value (to myself as the business supporting it) if it went online in August or if it showed up in November (like it did).  The key message here is to use business value (at the feature level) to prioritize and determine when capabilities need to be released.
  • All told my brainstorming, concept and goal development, initial writing, and technical setup to launch the website took roughly 12 hours – as mentioned above, this was 12 hours spent in short bursts initially, with longer work sessions to get stuff done as I got closer to a self-imposed deadline to get the site up.
  • The time spent brainstorming and documenting a “vision” amplified by “goals” quantified by “objectives” serves to provide a solid definition of “success” for the blog / site – having a well defined meaning of “success” has served to increase my motivation to work on developing content for the site in my very limited spare time.  I hypothesize that I will be more motivated to sustain the site, since I have documented goals that I want to conquer, and as I complete initial goals, I will define and adopt new goals to ensure that definition of “success” remains relevant.

The key learnings that I hope all can extract from the “4 Estimates and a Gantt Chart” debate are:

#1 – Planning is a needed and valuable activity so as to ensure all involved with a project (or product) have an understood and agreed upon definition of “success” – without a definition of “success” you cannot build a high-quality product.  Regardless of your context or project, how well do you know what “success” is, and more importantly, do you know how each of your day-to-day activities are helping to get you closer to achieving that definition of success.

#2 – Use business value to determine priority for when to stuff (projects/capabilities/features/etc) needs to get done – for personal / side projects use “personal utility” (what value does the project bring you) – if you identify something that has significant value (in either context) prioritize it and get it done.

#3 – Increasing your Work-In-Progress will decrease flow – this has been proven time-and-time again by kanban and lean scientists – techniques like personal kanban or pomodoro can help – they are most effective when you use them to track ALL of your side projects (recall you need to visualize everything going on within the value-stream for maximum benefit).

#4 – Goal setting works so as to make incremental steps towards the definition of “success” – just be careful to ensure that your goals remain relevant, if your objective changes, update your goals, if achieve your goals (which I hope you will) then create new ones – it’s like shampooing your hair: wash / rinse / repeat.

#5 – It doesn’t take 4 months to setup a blog, it should take you less than a day (or perhaps even less based on your success criteria) – if you believe it will bring value of any kind, just go do it – but remember if you are your own product owner, you still need to define what it means for you to be successful.

For those that are intrigued by Tice & Amos debates – next up: “Planguage” – a language all about planning, so as to provide a more precise definition of success.

… qed …

References:
Personal Kanban – http://www.personalkanban.com
Pomodoro – http://en.wikipedia.org/wiki/Pomodoro_Technique
Planguage – http://www.gilb.com/Requirements

Jamming in an “agile rock band” . . .

Uncategorized, ,

Recently I was asked for suggestions on how to go about growing a team of agile coaches within a coaching practice – knowing that sometimes communication is more effective using metaphors, I thought for a moment and came up with something that seemed to “resonate” – what do you think?

My idea was to channel your inner rock star (we all have one) and think about setting up an agile coaching practice as if it was a good “self-managing” rock band.  We all know that a good band needs a lead singer (since that’s who everyone wants to listen to); however, if all you have is a lead singer (a single agile jedi), you’ll have one voice with nothing else to back them up which doesn’t make for a musically diverse experience.  Next round out the band with some instrumentalists (guitar, bass, drums, horns – other coaches) and maybe even some back-up vocalists (newer coaches being mentored by more experienced members of the band).  Realize that each member of the band has a special mix of skills (the instrument/skill they have learned – agile examples: pattern based refactoring, single-team focus, enterprise-focus, executive-focus, CI, TDD, PMP, ITPM, SAFe, story mapping, lean, kanban, metrics, probabilistic forecasting, facilitation, games, etc), but moreover each band member has a common set of knowledge and understanding that enables them to work together – the band members may (or may not) know how to read music, but alas they have a general understanding of how their songs go (agile principles and values), and have an agreed upon goal to perform, so they can put on a performance – in “agile” lexicon, shall we call them T-shaped people.

Now we get to the fun part of the metaphor, which has caused countless “epic rock band blowouts” throughout history for which VH-1 has made countless episodes of “Behind the Music” – who is in charge?  When a rock band performs, it doesn’t have a conductor out in front telling everyone what to do as a symphony orchestra does – the band just seems to figure it out, or rather self-directs.  For a rock band to endure, the band members need to figure out how to effectively “self-govern”, learn how to resolve conflicts and differences of opinion between members that are sure to occur, and work towards an agreed upon goal of giving solid performances with some level of consistency.  None of the band members out rank each other – when it is necessary to make decisions, the band members talk things through and come to consensus leveraging the different viewpoints and experiences within the group.  Good bands also properly leverage the musical skills and abilities of their members to create a unique and defining sound.  If every song had a guitar solo and only a guitar solo with no other band members being featured, the audience might become tired of that, and you can imagine there might be a little bit of conflict back in the dressing room.  Good rock bands know how to feature each of their members when the time is right because they each bring something unique to the band, so as to deliver diverse and dynamic performances.  And let’s not forget that the lead singer can’t sing “All Night Long” (unless they are named Lionel Richie), so there are times when the lead singer leaves the stage (to change wardrobe and visit the roadies) and lets the instrumentalists jam trusting that they won’t send the audience away.

A final role needed to best ensure the band’s success from a business perspective is “a band manager”.  Let’s face it, most rock band performers are focused on how to improve their performances and want to spend their time singing or playing (new songs / new riffs / playing gigs) – if the band has to organize their own tour, that will take time away from their ability to create, innovative, improve and most importantly perform.  Hence the band manager handles the business of booking the tour and working to identify venues and audiences to which the band’s music meets or exceeds audience expectations.  The band manager helps the band maintain a proper balance of time on the road for gigs, and also time for off-the-road rehearsal and composing new music.  Most importantly, the band manager keeps the band in the spotlight where their talents are recognized and have impact, vs. just allowing the band to jam in the garage which although is great fun for the band members, it doesn’t necessarily allow others to benefit from hearing the band’s music.

That’s my idea – anyone wanna jam?

This is “TheAgileFactor”

Uncategorized

I have been long overdue to create some type of an agile-themed blog now, and for which I know a few of my agile-minded colleagues will critique the “Big Enterprise” tactics and self-imposed roadblocks that I worked through to get things up and running.

Getting Started via Analysis & Infrastructure

Right off the back, instead of doing the “simplest thing possible” (which would have been to start using a free blog site), I took a more long-term and strategic approach (which took some time to complete) thinking about branding, a messaging strategy, a target audience, and also setting up an independent site whereby I can easily extract my content (and the comments that I hope all will share) with me, if I need to do so.  The resulting plan was fashioned to supportive of a “free the data” strategy (a common theme in Enterprise Data Management practices), whereby it is considered a best practice to ensure that data within a system can be transferred to another system when needed to safe-guard against system/vendor lock.  The decision to create a site triggered a standard Enterprise Architecture envisioning process to identify possible implementation plans to determine what IT assets in my portfolio I could reuse vs. what capabilities I would need to buy or create so that I could have a blogging / content platform that met my criteria.  Most importantly, I wanted to cater to the user / reader experience, whereby I could control placement and types of ads – or ultimately provide quality content and ideas in an ad-free experience.

But alas, the site is finally up, the first post has been made, and you are reading it – success.  Granted  hope you keep reading . . .

“TheAgileFactor” Concept

TheAgileFactor is intended to provide thought provoking analysis, commentary and guidance based upon topics of interest within the “agile” and “lean” software development communities.  At their core, both “agile” and “lean” are collections of values and principles for which there has been much debate over what they really mean, how to apply them, and for which a market of consulting, training, guidance, frameworks, prescriptive methodologies, quantitative & qualitative metrics (of which we can debate their scientific merit), project management tools and buzzwords has developed.  As part of TheAgileFactor, I will highlight relevant and interesting topics and ideas, while perhaps sharing a few of my own.

The overall intent is to present information and ideas so as to help individuals, teams, organizations and even full blown Enterprises make incremental steps for improvement.  If you have come here looking for the “secret pill for software development success that works for everyone”, you won’t find it because it doesn’t exist (foreshadowing to an upcoming discussion regarding the “proper understanding and use of best practices”); however, I do hope to share practical advice and insightful questions that when applied against your current scenario may help you chart a course forward.  Initially my content focus is centered in the “agile” and “lean” methodology area spanning topics relevant for small teams up to large Enterprises.

If you have invested (or perhaps wasted) any of your time in the last 10+ years watching 24/7 cable news channels (those of you that know me, know that I have), you may know the highest rated cable news program (for 10+ years) is FoxNewsChannel’s O’Reilly Factor.  We can all debate whether or not “the spin really stops” on the O’Reilly factor, but to give credit where credit is due and putting aside political views, Bill and his production team have developed an effective concept / format for promoting awareness, discussion and commentary on much-debated (often complex) political / societal issues which is intended to educate and empower folks to make their own informed decisions.  I hope to do much the same with TheAgileFactor – hence the “Factor” branding.

Initially, I am starting with just written content, but have a “content roadmap” for which the future does include highlighting game & simulation based activities to enable improvement and future media offerings.  As you can see from the initial version here, sharing content and ideas are more important (to me) than style and design.  I will have to consult with my internal Product Owner (me) regarding what is more valuable: more content or pretty pictures & design – of course I value feedback from my customers and end-users otherwise I’d be living true to being an “Evil Architect”.

Other Content Channels

If you would like to broaden your “agile” awareness and learning experience beyond TheAgileFactor (without the need for continued reading), I also contribute to the “ThisAgileLife” Podcast (www.thisagilelife.com – also available on iTunes) using a variety of character / role driven personas – where I envision in future podcasts we may end up discussing Factor content.  I’ll suggest that cross-channel promotion is a key success factor in any digital content/media strategy chartered by a “Center of Excellence”.

In closing, while some may propose, I did not do the “simplest thing possible” to setup a blog site, I will argue that I did wait until the “last responsible moment” by setting up the new site (infrastructure procurement), loading the initial content (that had been pre-drafted and reviewed), and switching over my agile-themed twitter handle over to @TheAgileFactor just minutes before the recording of ThisAgileLife Episode 25 to announce that once again I’m online again.