Tips for Facilitating Meetings Effectively

“Never Perfect. Always Genuine”. – Lalah Delia

Some people have an innate ability to just assume the helm and guide others within a meeting. They are born with it. They possess the skill, the wit, the charisma , etc naturally and help people get where they need to be. I, however, was likely not innately born with this gift but consciously have worked over the years to cultivate this craft.

If you find that your role necessitates this skill or you have just been the lucky one to do this (or were “volu-told” you were the facilitator as no one else would do it or seems to be able to do so), these are just a few quick steps to help you do the best job possible.

Step 1 – Be prepared to facilitate.

Being prepared means a lot of different things to people as their are “planners” and “wingman”. “Planners” tend to want to have a strong map of how the meeting will go, have the materials they need in place and know how the meeting will unfold. All good stuff right?

“Wingman” go in cold, have a general idea of what they need to do and because perhaps of their ability to speak and interact use this as the basis that will carry them through. They are more often interested in the conversation that occurs than the regimen of a plan.

Well, from my experience, it is always somewhere in-between. No plan comes off without a hitch and endless conversation with no guidance is not something that leads to a productive end. This is why I use the term “prepare”. You can prepare for what you want to accomplish but leave room for things to just happen. I look at this like having some basic car emergency supplies. I have the basic items I feel I might need, jumper cables,  road flare, small medical kit, however, I could need more. I personally would never say “I’m covered” and not take my phone to call a tow truck or say, “I am experienced in life and the experience of the open road” and just say, I don’t need anything as I can handle it as it comes. This provides me with options and a choice of how to proceed, or deviate, in the face of some emergency.

So what do I mean when I say “be prepared to facilitate”?

  • Do your best to know your audience. Do you understand their business or can you relate the goal of the meeting closer to them so everyone can share a vision. Do you have dominant talkers or people you have to draw things out from. You may not get this insight and have to read the room but understanding the players of the meeting can be helpful even if you do not know the entire room.
  • Prepare in a reasonable manner. – Are you going to lead the group? If so, know how this will unfold and be prepared to deviate as needed. Have post-its, whiteboards, markers, etc. Possibly even provide Kinesthetic items for people to occupy themselves as some people think while their physical is engaged differently without creating distraction. For some people this helps them focus and process information.
  • Establish some boundaries of the meeting up front. – Try and meet with the key sponsors of the meeting and negotiate with them boundaries for the meeting forr success. What I mean is establish general interaction policies such as “will you allow cell phones and laptops/tablets in the meeting” or will you provide as part of the agenda (based on the group) a recurring break to check these devices. Will you use the “you are an adult policy” and allow them to step out and take calls or leave to use the restroom at any time? Can you clearly state that the meeting will proceed and that if they not present, the work will move ahead with or without them? When is lunch (is it provided)? What are the schedules of the people can they commit to an all-day meeting or is it better to hold small targeted “mini summits”?
  • Do the pre-work for the meeting whenever possible. –  Establish an agenda and understand the goals and actionable items that the meeting is trying to reach. This will allow you to have a defined boundary to redirect conversation or to keep people moving towards an end goal. Make it visible at the start of the meeting and cover it upfront like making a contract with the meeting. Ensure that you clearly state the goals and actionable items that the meeting is seeking to achieve. Repeat deliverable expectations at least 3 times if necessary to solidify the importance of those needs if possible.
  • Use the concept of a parking lot to table off-course ideas. – Gino Wickman, author of the Enterprise Operating System (EOS) indicates that in a discussion that in his system, that a general rule is the “rule of 3 times”. If a person states a point, reiterates the point, once they state it again, they are merely politicking to sway others to their side of opinion. Be keenly aware of this. We have all been in a meeting where Bob states the same thing over and over and everyone silently thinks “here goes Bob again, blah, blah, blah, blah …”. Help keep the flow of the meeting going by acknowledging Bob’s point but suggest if off tract or bogging down the meeting that to ensure that the goals of the meeting are met that we note his valued point or concern but that to stay on track, we may need to move along and circle back around to it once we achieved our goals. This can be tricky, Bob needs to understand that you hear and value his comment but that for the good of the meeting, we have to keep moving forward. This can be especially tricky if Bob is a “C” level executive but in doing this you are courteously acknowledging his point, keeping it visible but steering the meeting to the end objective and demonstrating your commitment to the meeting satisfying its goals. Indicate items that may need their own potential meeting if the topic goes deeply enough.
  • Move big items out of the way in lieu of progress. – As you go through items, occasionally you will encounter an item that in the scale of “solve world peace” which someone thinks is  reasonable discussion topic. Whereas on face value the topic is truly valid (who wouldn’t want to solve world peace) the overall scope may be far too large to make any real tangible progress on the topic. Unless you are going to take this epic level idea and indicate small actionable steps to move in this direction, you will unlikely (even in an all day meeting) solve world peace. Accept this and move it to an area for later decomposition or create a breakout session to breakdown more tangible goals.
  • Let healthy debate happen –  One of the most difficult things to do (and I always have to be aware of myself in this behavior) is “being silent” and listening as debate happens so you can distill the end point. As human beings, we often very social in nature and interaction is something that is hard for us to suppress. It is often difficult (especially when trying to help people reach a goal) to remain silent and allow them to discuss their positions and even openly disagree. It’s hard not to “find the peace” when people are openly disagreeing. Listen to the flow of the disagreement and see where you may need to interject to parking lot the disagreement or possibly summarize the key point of disagreement, gain acknowledgement of the point, make it visible and move on. Read the room, what is everyone else doing during this? Have they disengaged. Actively work to not lose the momentum of the whole room because of this disagreement.
  • Be the introvert’s advocate! – If you observe dominant talkers in the room, try and find ways to engage others and for those that you may feel are providing little input, seek ways to get confirmation or dissent from them by asking “do you think might work” or “I would be interested to say what (person) has to say”. Work to create ways to give the entire room a voice. Explain to the group up front how you may redirect someone if you see that a person is being silenced or having their thoughts completed for them. Be courteous but be vigilant to get the right ideas to the table.
  • Respect the time box. – Start the meeting when it is slated to start (giving human error leeway), take breaks early or when scheduled and ensure you are consciously focused on getting actionable items identified wrapped up and recapped by the close of the meeting. Do not disrespect people’s time by keeping them longer nor allow others to disrespect time waiting for people to come straggling in. State your appreciation and contract to respect people’s time and honor that commitment.
  • Recap the event. – Ensure that you recap the accomplishments of the event by closing action items (or doing so recurring to show progress), state any action items and owners to shepherd the items outside of the meeting, state outstanding  items with a plan of intent to address them. Thank everyone for their time, attention and participation and wrap up the meeting.

These are just a few helpful tips to think about when placed in a situation of facilitating a meeting that can help you be more successful and work to achieve a stronger outcome.

 

Advertisements

My Ideas for Hiring and Onboarding – Part 1

“Mistakes are the best lessons while experience is the best teacher” – Anon

One key piece of agile leadership is the deeper understanding that the people that are doing the work are a core component to your success.

As a leader who personally cares about the organization that I work for (as I do with any employer that has a mission that is aligned to being a more progressive and agile group) I spend a lot of time thinking about people. Not only the people who are here today as staff members, but the people who will join us from the trails we set today.

I often ask myself a continual set of questions:

  1. Is our hiring process (as much as what is under our direct influence or control) optimized and are we keeping it fluid to change to the changing landscape of hiring and the changes in the market?
  2. Are we using hiring practices using a balance of demonstrated skills but remaining open to closely listening to how people think through problems to discover potential undiscovered gems of employees with lesser demonstrable skill?
  3. What is the end user experience of our employee on-boarding after the hire? Is it consistent, cumbersome or does it provide them with something that begins positive employee engagement? Are we gaining feedback?
  4. How do we setup our hires for success in terms of tooling preparation for their job, understanding our technical, diverse social, political and cultural environment and celebration of them joining us?
  5. Are we learning from our experience and examining the ways others perform this process on a routine basis?

I ask these questions and I will be open and admit, the answer is not always a resounding “YES” in my mind. And this … always troubles me. My desire is to create an experience of joining my teams that makes you excited that you are here and ignites that initial spark to not only do the job that you were hired to do but to find a way to be a part of improving the culture as we move forward.

I freely admit, that as a leader I often suffer from the inner struggle of having ideas bouncing around like bumble bees but not always having all of the support I need to align my vision to the end real outcome. I have learned to understand this about myself as it creates a constant inner tension of “there is more I can do” which is both a positive drive but can be draining (which means I have to allow myself to level set and recharge when I since this).

But I began to really think about what this overall process looks like to me and how I might advocate to try an implementation focused on:

  • Hiring the “right candidates” that provide value-add to the current culture in helping it grow.
  • Providing an onboarding experience that is timely, engaging at both the micro and macro levels of the organization and provides a positive experience that engages and supports them from day 1 and that learns from doing.
  • Create an opportunity to “prepare them for success” in their new role through proper tooling and focused education and direct experience before introducing them into their daily routine of their role.
  • Possibly hire them with other team members so that through the process an underlying sense of bonding can occur to create a secondary support system when they transition to their daily work.

Many of you are reading this right this moment and thinking, “big deal; my company does that” … But my company is part of the public sector serving citizens and concepts like this are not the mainstream of thought and definitely not the concepts of the people in leadership. But I have always been one who asked “but why couldn’t we be this”?

It may be often more easy as it may be when the company is owned by a group of share holders or private investors but just as they have concerns over profit margin, the public sector always has to consider the responsibility of fiscal trust granted through being financed by the public (even though some betray that trust I know).

How hiring often is done today in the public sector

When I started in my current role, hiring was very suspect to me in the sense that it did not typically contain any form of demonstration of possessed skill for securing the position for which a person was applying.

It was usually 100% conversationally based or had a minimal “test” for skill that was often used to determine “right or wrong” as the answer subjectively (which code implementation can often be) without any real understanding of the person doing the work. I have often said many public sectors went like:

Employer: “So I see on your resume that you have N years of experience in technology X”?

Me: “That is correct. My most recent experience being (blah blah blah)” – This is where I regurgitate my resume and add some detail.

Employer: “How would you rate your skill from 1-10 with technology Y”?

Me: “I would say I am a 9 as no one is perfect. Fill in details” – This rating means nothing as no one actually knows what the scale is for each increment. Years? Lines of Code?

The review of my resume and asking questions derived on the spot from it would continue …

The conversation continues (for at least one hour) and often if there is a click and the resume seems fine, the conversation degenerates into basic technical chit-chat. Boom. You are hired.

But what is the glaring issue here? You have absolutely no idea, except from my exceptional resume, if I know what I am actually talking about other than perception. We did not discuss anything tangible to the skills you needed for the position. It was primarily based on what I told you I had done and provided on my resume.

This is of course a very simple viewpoint and not taking into account many people who interview, like myself, that may have worked with solid team members who knew my caliber of work and could vouch for such effort and skill to the hiring manager.

And worse, many public sector hiring managers operate under the assumption that if you do not work out during a “probationary period” that you will be dismissed. This rarely happens as they do not have the uncomfortable conversations with the employee during this period informing them that they are not doing the job as to be able to justify that release (a requirement of public and many private HR policies).

How did we change our approach to hiring?

When I assumed my current role one of the first things I sought to do was 2 things in reference to the hiring process:

  1. I wanted it to be more in line with general private industry hiring practices that invested more deeply into hiring practices so that it required not only an employee to invest deeper into the process but also combine it with some base skill exercises guided with the hiring team to see skill level and how they thought through problems.
  2. If the right candidate did not show up for the interview (meaning that they were someone who “might fit” but we did not feel confident in them) that we would not hire out of desperation of losing the position, frustration of starting over or to fill a quota. I had experienced too many times that hiring managers would hire “the best person who showed up” and compromise the position as to not have to jump through bureaucratic hoops again.
  3. I wanted to utilize grass roots recruiting and look for ways to personally connect with potential candidates when possible to demonstrate to them that work in the public sector for a technical person can be fulfilling and have many opportunities for serving others as well as provide an opportunity for some benefits not seen when joining a startup or boutique development company.
  4. I wanted every single candidate that left our interviews to have felt challenged to earn the job and the experience we created through the process to make them want to join us, even if they were not our selected candidate.
  5. I wanted the hiring process to be focused on “what we needed” in a broad sense and just not distill to a checklist of technologies or experience.

The first thing I focused on was making the hiring process more meaningful to hire the right people through a deeper and richer hiring experience that focused on learning more about the candidate from a behavioral and technical viewpoint.

Together with my leadership team, we implemented a two fold approach in which a hiring panel would first have conversations around concepts of behavioral based questions (for about an hour) to begin to gauge their thinking process around typical issues or team situations common to the role followed by 2 hours of more in-depth technical exploration and hands on work ending with a pair programming exercise in which they were the driver in the scenario for developers and other scenarios based on the role. This worked out really well for a couple of reasons:

  1. It allowed us to give them the opportunity to relate previous experiences of situations and shape the questions around what they learned from the experience or why they took a specific course of action. This allowed us more insight into how they reasoned through a situation from the most routine to the most challenging within their role.
  2. It allowed us to examine the candidate from a technical point of view apart from trying to get to know them in terms of personality and really focus on what they already knew from a technical perspective but also how they reasoned through areas they did not know or how they approached something to which they had little or no familiarity. Did they try to BS their way through? Did they openly admit they did not know and not try or did they tell us about their lack of knowledge in the area and reason how one might approach something or use a certain technology even without that knowledge. The first 2 gave us insight into the ability to be humble in the face of the unknown and how they handled this but the latter opened us up to see the potential of a person’s growth with us and often led us to finding people who we could see wanted to know and had that drive to learn. Learning how people think through a situation can be as invaluable as just the right answer.

We always de-briefed after a hiring process not only to decide on a potential hire but also to talk about how the process went overall. We used the concept of a retrospective within our hiring process so that we could seek improvement the next time or adjust things that were not working. This was tremendously helpful and a far cry from the ending of standard hiring cycles I had experienced before. It incorporated the potential of improvement through reflection.

It allowed us to not only to apply agility into our people operations through inspection of the process but to allow us to gain better insight into the candidates coming in a bi-modal manner within a more reasonable timeframe for a technical interview.

What were our initial constraints that we had to work around?

  1. Public sector hiring is a highly regulated, rules driven system that has fixed timeframes and candidate constraints and posting for positions is often outside the hands of the hiring organization but rather handled in a centralized manner using template position descriptions.
  2. There are minimum educational qualifications that preclude candidates without a formal college education (and matriculation) or significant enough experience within the given field from qualification that can exclude many candidates. This meant that often people without formal education or experience fell beyond our reach. We could not just hire a technical savant that had never done anything or had any IT degree based on the hiring system.
  3. Protected class groups are given some preference in consideration (not preference in hiring) and justification must be made when not hiring a candidate from a HR protected class. So we had to ensure that if we rejected a candidate it was for sound rationale, not a gut feeling.
  4. Large scale private sector hiring processes are not unlike large public sector hiring processes. They are often slow and there is delay from groups external to the hiring group to confirm the hire, mandatory processes for which the information must pass, established formats for hiring submission for consideration by hiring managers, etc.
  5. Salaries, especially public sector technical salaries, are often non-competitive with private sector positions and often specific job classes simply do not exist meaning you have to employ grass roots marketing to use a position in a different manner and have people apply through personal recruitment. We had to consider a “hire and grow” strategy to remain competitive with the market and for more seasoned people we needed to find those that wanted a better balance in terms of their career and life needs.

Some, or all of these challenges are not uncommon to any person who hires within the public sector. So how did we address them?

We actually were fortunate to have a local human resources leader and team that wanted to ensure that we understood the process but remained open to conversations about what these obstacles were and work to address them with the centralized hiring authority. Forming a relationship with the HR team and understanding their world and the constraints under which they are responsible helped us work together to find the best way to work. There were some things we could not eliminate but what was possible was examined. Creating and maintaining this partnership helped us understand and better traverse the system of hiring in the private sector.

In my opinion, these partnerships are critical. The overall process is fraught with its own rules, domain language and understanding. Having people that can assist and become a partner that understood this world better than I became tantamount to driving towards a new approach. I would highly recommend that people desiring change in this space of the process build these partnerships. Without them, you are trying to traverse a system for which you may be woefully unprepared to understand all the nuances and aspects to this approach. These partnerships have been invaluable to me in understanding the roles and responsibilities of the HR system in the public sector and the things that I do to assist them in helping me get things accomplished when it comes to hiring staff.

Grass Roots Marketing

One of the things that was very important to us, and still remains a primary focus, is to share the story of our environment and culture with others that may seek to join us. We have spent time connecting with the local community and seeding the work we do to others as well as creating a significant “word of mouth” through our past hires and ongoing meeting with local groups such as software schools and developer meetups.

Often times, many large scale private enterprises have much more capital that they can put behind their hiring and recruitment processes. So, as a public entity; you often must become creative and put forth more personal effort without that budget to assist you.

We are very fortunate that our HR team understand the benefit of recruitment and is very progressive in the way they think about attracting candidates often hiring domain specific staff to help them understand and connect to the areas in which they are recruiting. This deeper understanding of “why” people want to come to work somewhere and the personal investment in the candidate is in alignment with our thoughts as well.

Staying connected as often as possible to groups to share the view of your environment and culture helps potential candidates get a better idea of who you are and why they would want to be a part. We are always thinking about this message and how it can help us attract the right people into our culture that can continue to be a value add and help us grow today and shape what we become in the future.

The Follow-up

The public sector, hiring often fails as the transition to potential candidate to “new hire” breaks down in the lull of the process. This is not unlike larger scale private enterprises but what they seem to manage much better than public sector is the process of pre-onboarding engagement.

We found a lot of our potential hires did not have the understanding of the lumbering beast that can be large enterprise hiring processes. It often involves multiple groups, departments, sign-offs and approvals. In a larger environment, the processes are often streamlined more for oversight than for speed to on-board. So it becomes critical that you become good at retaining that engagement during this process. Most people, even though excited, have some nervousness about starting a new position. I think a great deal of that stems from the unknown of the new job and role as they only get a small glimpse into the organization during the hiring process. We made visits to local bootcamps to educate potential candidates about the difference that applying to a larger scale enterprise company can be in terms of times so they understood this better.

This is a great opportunity for you to use that tie to help them gain a better picture of what their first day, their first week, etc will be like when they join a company. I have seen many companies that are master at this seeding periodic information to a candidate during this process so that they feel a part of something larger. This is something, as a public sector organization, we can become better at and do effectively without a large scale investment. Here are some examples:

  1. When hiring someone in the public sector, know what the average process length might be and set the expectations up front when hiring someone. The worst thing you can do is have a candidate wait in a black hole and wonder if something is wrong. Connect with them regularly to let them know about stages in the process and pass along helpful information to allow them to prepare for their new job.
  2. Send a personal email welcoming them with information about benefits (or pointers to benefits) that lets them know more about their group. Consider creating a marketing document or website that lets them get to know people before they arrive in some manner and gives them a glimpse into reinforcing why they chose to come work for you. If you have materials that introduce your culture and how you work, get it to them during the interim.
  3. Encourage questions and connection. Be accessible to them if they think of a question, find the answer for them or connect them to the right people.
  4. Organize something after work so they can interact with their new coworkers. Invite them to connect over coffee or drinks so that they makes those pre-connections before they start.
  5. Send them a final confirmation of employment when all is approved restating the salary, start date and pointing to benefits. Send an employee handbook and other materials that might be useful as well as anything else they need to experience the least amount of friction on day 1.
  6. Prepare for their arrival and have a consistent on-boarding process to help them be setup for success. Confusion and red tape starting day one is a great way to leave a sour taste in someone’s mouth when starting with a company. Having there location, tools and access in place demonstrates that you were focused on their start, not that it was an afterthought.
  7. Give them a voice in providing you feedback about their experience. This not only demonstrates that they do have an active role in the organization and use their insights to critically evaluate what you do. Keep the process as lean as possible so that you can change as needed.
  8. Realize that starting a new position is change and with change is often fear of the unknown. Meet with the team that they will work with prior and express your expectations of growth so that neither the team nor the new team member are confused about the organization’s expectation of their progress.

In this blog post, I have discussed the prior hiring process, how we approached it in a different manner to hire today and why these things are important and how we can set them up for the best outcome in the public sector.

In part two, I plan to diverge more into how we might consider on-boarding new candidates and explore some of my personal thoughts on ways outside of what we do at my organization that might further enhance the approach or different ideas that someone might try.

I end this post with a quote that I think embodies the importance of this activity:

“The most important thing you do as a leader is to hire the right people” – David Cottrell

The Effects of Accepting Bad Work

“Leadership is not a title. It’s a behavior. Live it.” – Robin Sharma

As career people, we have all had a bad manager likely in our career. Those that utilized command and control, meddled in the lowest levels of work, micro-managed or did not really understand what the crux of leadership really should be doing.

I have a very general treatise when it comes to those that I lead and manage.

  1. My staff have the freedom to challenge anything I say. – I do this because there is no possible way I can know everything nor can always be right. I can determine a course of action and lead with conviction but without the ability to hear the potential problems I might not see, I could be “the blind leading the lost”.
  2. Don’t push people out the door but don’t stunt their growth to make them stay. – Keep people learning and growing and work to ensure that you are not setting yourself up for failure through starving the group while feeding one individual.
  3. The culture and environment should inspire people to want to come to work. We spend far too much of our lives doing work to be in an environment that does otherwise. I have worked in those cultures where it was a real battle everyday to come to an environment even if I still appreciated the work that I was doing as was paid well to do it.
  4. You should constantly look for “bright spots” in the people that are a part of the culture and cultivate them however possible.  I want to be aware of people who are growing and encourage that growth through stretch assignments and opportunity. I would rather have a great team member leave my organization and go on to greater things than to have a mediocre team member stay and hold back the overall growth. Give you team members the ability to regularly learn and grow!

One of the things that I see in some leaders, and I have been guilty of as a leader myself early in my career, is allowing myself to accept bad performance from someone far longer that possible and not guide the situation either upward or outward.

After reflection on this situation, I really got to thinking about what the ramifications of leading in this way really do. I began turning over the idea and looking at it from more aspects than just leader and team member.

The potential affect of accepting this bad work

What this communicates to the team member

When a leader recognizes poor performance or work product on the part of a team member and allows this to continue, they often set the stage for a couple of things:

  1. The outwardly communicates that this level of work is the accepted norm to the team member and as a result they may never stretch themselves to do more or make think this is all that is ever expected from their job. This could lead to complacency on their part of push them out the door as they are bored.
  2. Leaders often become frustrated over time (likely from the guilt of not addressing the issue itself ) and are often reactive to the situation in the future without giving the employee insight into actually doing something to improve their work. This can be coupled with a lot of emotions around having the conversation about the work, which have compounded if left unaddressed over time..

What this communicates to the teams

  1. This shows a lack of care towards the teams themselves. Most teams that are self-organized will adapt to ensure that they still hit the mark of delivery even if they have to compensate for a bad team member. But they will begin to resent a leader who places them in this situation long term.
  2. It communicates that leadership is not really connected to what the teams do (or perceived that way) and is not really supporting them. I am not talking about micro-management here, I am just talking about the team feeling that they are drowning and no one  cares.
  3. It begins to communicate an expectation that the quality of work doesn’t mean anything to the culture.
  4. This can again breed with it a strong amount of emotion that makes it personal towards the underachieving team member or towards the leader or the organization.

So what to do to address this issue?

  1. Have an open conversation. Not tomorrow, not later, not when it “might feel easier”. As Nike says, “just do it”. Having a conversation over bad work performance is terrible.. Accept this and move forward. No amount of time will make it “less worse”.
  2. Understand what the impact is to the work and the team and be able to clearly articulate why the work is a problem. Don’t fish for words or try and make it sound “not that bad”. Just be honest and indicate the problem. Maybe this person is unclear of expectations. Just be able to state what the problem is exactly. And if the person needs to vent or rant or defend, allow them some space but do not try and soften it by discussing it to death.
  3. Be able to clearly articulate what the expectation of work is for them. Don’t leave them guessing. Do not give them micro-management but give them clear end goals and restate the team impact when not meeting the goal. Help them understand what success looks like.
  4. Provide a follow-up plan with clear checkpoints. Ensure that they know whom they can speak with if they have problems and ensure them that these checkpoints will ensure if the situation is getting better or worse and allows them a definite point in time to “pivot or persevere” in how they are working.

Overall, just be aware that the acceptance of bad work has impacts far beyond the work just not getting done right. Accepting this can eventually erode foundations of a good culture and a good team.

Until next time live well, lead well and stay agile!

 

Don’t Undermine Agility

In the book, “Drive“, author Daniel Pink talk about the primary underlying motivators of people based on research. He indicates that these are:

  • Autonomy: The desire to direct our own lives
  • Mastery: The urge to get better and better
  • Purpose: The service of something larger than ourselves

 

Each one of these elements can then be decomposed even further such as:

  • Autonomy – Giving an individual more control over where or how they work
  • Mastery – Providing recurrent opportunities for investment into skill growth or activities that provide both stretch and deliver propositions for the individuals or teams.
  • Purpose – Making the “why” of what they do highly visible or helping them see how their work contributes to the business as a whole or what impacts that they make through the work they do.

In my experience, these core ideals have always resonated me and they have been used within the culture we’ve built in my organization(although it could be more widely accepted):

Autonomy – We work hard to nurture the separation of the “what” and “how” of the work to be completed focusing the teams to have the freedom to have deeper ownership of the latter. We have balanced this by helping the culture find the value of conversation to find the best solution to meet the highest value. The best idea comes from where it comes from but no one has “carte blanche” to beat anyone into submission to follow their idea.

We utilize a remote work policy that is centered around being a professional and taking the work commitments seriously. Our teams are professional enough to understand that they have the ability to police themselves and have support from scrum masters and leaders in they see that someone is not pulling their weight or may bring it up for open discussion in a retrospective without fear. We expect notification as leaders so we can be responsible for knowing where our people are as a professional courteosy, that they have discussed it with their team and scrum master if they know they need to be offsite. We feel like this is polite notification as opposed to restrictive and teams seem to agree.

We use the general philosophy that “life happens”. I recall personally working jobs in which the expectation was that I took a vacation day for having an appliance delivered or having to take a sick day when I might be too unwell to make an hour commute but could have continued to contribute. By using this underlying idea, we communicate that we understand that people have life obligations that happen and we accept this and are willing to accomodate flexibility in where and when people work as long as we are still getting the work done in the best possible way and not degenerating into remote silos.

Always remember that if the tools and processes you are using carry so much overhead to ask a question, find an answer or interact effectively, an individual is more likely to make a decision in a vaccuum than take on the burder of the overhead of communication.

Mastery – We have realized this in several ways:

  • We provide recurrent week long hackathons to allow teams to focus their creativity on thinking about interesting ways to solve a problem or extend a product. This is focused around exploration of an idea and focused skill work, not product deliverables.
  • We provide to each and every member of our group a pluralsight account so that they can take advantage of learning within their schedule anytime.
  • We have designed our 13 day sprint cycle with purpose to account for a single day each sprint dedicated towards self-learning, skill building and growth. This provides and opportunity of almost 3 weeks of self learning spread out through the year.

Purpose – This is one that I think we could work on more but we do try and nuture product owners to really explain the end value gain that the business receives from the work that the teams are doing. This has often been promoted by talking a field trip out to the field to meet the end recipients of the work and allow them to explain what they do, how they work today and where their pain points lie. This often creates a solid empathetic connection between the team and the stories that they meet. Sometimes just understanding the history of the work being done, why it is done and what it does for the end customers can help them find connections.

Finding opportunities to allow teams and team members to connect to the business as a whole to learn about what it does outside of the product work would be a solid long term goal and is being developed by our Human Resources team within a learning portal.

One of my goals this year is to determine how we can utilize some of Diana Larsen’s ideas suggested in “Liftoff” to connect teams as early as possible to create deeper understanding and allow them to be directly involved in shaping the work such as story maps and user story decomposition as well as using ideas to connect them better to how their work connects to the business.

How you can undermine your own agility

Often, I have observed that people will do wrong things for the right reasons and wonder what happened to the organization that they created. The group they once believed in starts becoming less agile over time. Please watch and mitigate these issues should you see them begin occurring.

Autonomy – You begin stifling ways of individual work. If you begin to lose focus of where people are, what they are doing (especially in being asked by executives) or “situational emergencies” are seen as only possible to be handled onsite. You begin to predict the schedule based on ideas of when and are not open to the conversation of what as part of that equation. Your actions start communicating that you have a level of distrust in the work of teams as expectations and delivery are misaligned. You develop a culture that wants to “see people” more than it values “the work that they accomplish”.

Focus on schedule begins to overshadow value. You set dates in the sand for features based on limited information and begin eroding the team’s ability to provide you input into complexity and delivery to make value based decisions.

Mastery – There is an old joke in which a CFO questions a CIO about the money being spent on training. The CFO states “what if we train them and they leave”. The CIO replies “what if we don’t and they stay”?

In a creative field, the ability to grow with the industry and get better at what you do is often a core part of your career. It helps you promote, it helps you move to know companies, it often refines or grows your ability to lead either technically or otherwise. Becoming better, is a core value to being a creative worker. Sure, you may eventually hit a pinnacle in which you either trade those technical skills for a new skills or you get to a point where the languages become secondary to the patterns upon which they are built. You see languages as tools and the patterns of how they work become more transitive. Basically a creative career without growth means at some point, you will get stuck. The industry will move away from you. It does not need to sleep or play with it’s kids or spend time with its family, people do. With this being said, I cannot see how any organization that seeks to achieve any longevity with employees would ever consider not investing into employees. It’s a fool’s bet if you do not.

But there is a significant cost to this investment if using conferences, learning sites, etc. Which in the grand scheme of budgets is far smaller than people think, in my opinion. But there is something you can use and that is opportunity. Sure, it has the cost of allowing someone the time and freedom to learn and grow. But the pay-off of staying relavent and having employees who are constantly honing their craft is a good thing. Often time, bottom lines of budget can drive these. Look for every opportunity to keep continual learning alive through peer to peer sharing, local developer talks at lunch and learns or even reducing a team member capacity during sprints to allow them to learn. Find opportunities to showcase what is learned to your group as well as the business.

Whatever you have to do, do not allow obstacles to cripple your team member’s approach to mastery.

Purpose – General George Patton was quoted to tell his troops “Better to fight for something than to die for nothing” in terms of his deep patriotism. Teams and team members want to know that they are doing things that are impacting someone.

I have often said that my affinity for public sector organizations has been because “I would rather create a product that helps a secretary do her job a little better than to make a 10% profitability increase for a board of shareholders I never see; even if they give me a bonus in the process”. Maybe it is because I started in the social work sector before I moved into IT in business or maybe it is because the work holds less meaning to me personally when the measureability is based on profit alone.

In general, people want to do good. I have never met an employee or a team member in my entire career that came to work and said “I am going to do the absolute worst job I can possibly do”. They may be incompetant, poorly trained, not a team player, above their head, etc. but they did not intend to do a bad job. I often remind teams that perform legacy work who complain about older code that many times the developers who wrote that code were doing the best that they could with the tools that they had and within the abilities they possessed. They were just trying to get a job done and help someone. They did not intend to write code that they expected anyone besides them would ever support, let alone, complain about.

I recall being part of a team building a system that at a certain point we began calling it the “Titanic” as we joked often heard the ribbets pop as we scraped along the iceberg. The project scope grew uncontrollably and it became death by committee with each person fighting for their individual wants and making it difficult to get any one thing of value completed. In the end it became a bloated system of 80% features.

The reason I mention this project is that it took the team a LONG time to become frustrated even after the chaos started because we believed in the underlying mission of what the system was going to do. It was targeted to help kids. And help those people helping kids. It was going to ensure that they had better care, they got connected more openly to services and community. The vision was amazing and each and every team member was on board. We watched videos showing vaporware and shed tears at the good we were setting out to accomplish. We were connected to something larger than what we did because we knew how it fit into the world that it would be released to. It inspired us, it elevated us, it pushed us, it connected us. That vision drove us even when we as technical professionals should have know that the end was near as we understood what the purpose of the work we were doing was.

Disconnecting your teams from that purpose is a mistake. Sure, we have systems that are like “hello, this is our accounting system. it handles our payroll and benefits”. But what is the purpose of that system. For a team, this is the system that ensures that people are paid in a timely manner, insurance benefits are kept up to date and vacation time is accurately stored. Without that system, we couldn’t pay people, people could not take vacation and if sick, people might not have insurance if inaccurate information is stored. It helps us apply raises and bonuses that pay for the needs of ourselves and our families. The people that use this system do not ever want to be the ones that have to email everyone to tell them they are not being paid and rent and mortgages are late, etc.

Sure, payroll is dull to me, but it has a purpose, a need, a vision and a connection to the business. If a team is being asked to do something on a payroll system, the “why” is important. Are we speeding up a process? Are we adding a new feature? Are we making a problem go away? Are we allowing people to do something easier or better? Understanding this, can create a better connection for the team to do the work. Reinforcing these things with personas, story maps, etc can even inspire them.

Don’t decouple the “why” from team work. Don’t reduce it to “cause Bob says they need this”. Understand the why. Help them understand it and form a connection with it. Taking the time to do this will allow you to continue to remain agile and continue to support a quest of purpose for teams and team members. It will allow they to understand the business terms, frame questions in business ideology and connect to d the end goal they are trying to achieve.

Final Thoughts

I decided to write this article as I reintroduced to the concepts of Drive in some reading I was doing lately and thought about how we apply or should apply these ideals in an organization. They are some good core concepts upon which to build an organization that resonates to the base needs for people (and remember those needs may be broadly unique as autonomy for one does not mean the same for others so think broadly about what avenues you support and what you reject.) and how these items can become corrupted as you introduce less agility or embraces practices that work against their nature. It’s not to say that experiement and reflection are not a great way to see the impact of things. Agile is all about, I am all about it. But be open to impacts of things in a organizational way and don;t be afraid to fail or be wrong. Be an organizational scrum master and protect the teams and team members by protecting those things that helps keep them focused and productive and meets the underlying needs. Remove impediments and reflect often. Be open but be vigilent…

Stay Agile!

 

Thinking in Moments

“Capturing the moments of today will wow your hearts tomorrow” – Anon

This will be a relatively brief post but wanted to share something that struck me in my early morning reading (which is my habit to feed my mind a little to start the day).

I am currently reading the new Chip and Dan Heath book, “The Power of Moments” in which they explore the idea of what defining moments are in terms of people and how people can make the shift to begin thinking in moments so that they can capitalize of the impact.

Doug Dietz, an engineer from General Electric spent roughly two years designing a new MRI machine. The book describes how he was so excited to see the first patient in a children’s hospital be able to utilize his creation but was absolutely dismayed when the experience was met with fear. He said this was the point that he “saw the room through the child’s eyes” which was cold and sterile and his machine sat inside like a “brick with a hole in it”. As a result, many children had to be sedated to undergo the use of the machine just to allow them to stay still and overcome the fear of the experience.

This heart wrenching experience fueled him to take this “pit” (low point or negative experience) and strive to make it a “peak”. So he worked with a vast cross functional team and was driven to redesign the user experience for children. The end result was he and his team created MRI rooms in children’s hospitals that resembled a pirate ship, a space ship or a amazon adventure (this one encouraging the child to stay still as not to tip the machine painted as a canoe). He careful observed the difference in the experience and was delighted when one small child tugging at his mother’s leg asked “can we come back tomorrow”? He had taken a “pit” moment for these children and transformed it into a “peak”.

I read this and thought to myself, “this is so applicable in organizations”. How may “pits” are we aware of as an organization for people (poor performance, bad service, bad product interaction) for which we have no plan or allow it to sit without putting passion behind turning it into a peak?

Conversely, how many “peaks” (employee first day, retirement, significant life events, transitions in career or life) do we place the minimal effort into a miss the power of creating the moment of connection between people and our organization.

This brief story really impacted me and I began to think (and I feel like I will begin to formulate known moments that I think I am missing for my organization) about what I could do to “think in moments”.

How about you? Are you thinking in moments? Are you turning “peaks into pits” or “pits into peaks”? I have not finished the book so I cannot give you a full review just yet but I can say that this small concept resonated with me and I am sharing it with you in hopes that it might with you as well.

Stay Agile!

 

Team Metrics

“The past cannot be changed, forgotten, edited or erased. It can only be accepted.” – Unknown

Let’s Define some metrics!

I had a conversation with a relatively new scrum master recently who was working to help establish some base level team metrics for their organization. They had made the journey to scrum from the role of a project manager and seemed to really transition the mindset of driving to create an environment of trust and transparency within a team and shunning the ideas of controlling the time/budget/scope and “resources” (word I hate when it comes to talking about people) viewpoint of traditional project management.

So my initial question was “who are these metrics being designed for”? This is something we often do not consider. There is a different need for reporting transparency and one to help teams improve. If oversight is the driving goal then the assistance to the team may become minimized. If the goal is to create metrics that are learning opportunities for the team or generate insight for a conversation then the construction of these may be much different but may provide less insight into what management may be seeking.

All metrics are not created equal …

Except, when it came to metrics it seemed. Most of the metrics they were developing were centered around trailing level metrics (lagging metrics for those who are KPI inclined) for the team. A lot of the focus was on the past as a predictor. So I raised the question; “why are you so concerned with the past” in terms of metrics?  They explained to me that this is how he could help the team improve by knowing where they failed or made bad decisions beforehand. So I asked again “given the dynamic nature of iterative development, how can you ensure that the same cause will generate the same effect”?

We discussed in detail that they were extremely proud of was the tracking of “estimated” versus “actual” hours on tasks. They worked really hard to convince me that learning the difference between the two would help them more accurately estimate the work to be done. I let them go for a while and then I had to call bull%^#$ on this.

In my opinion, the only way an “actual” at a task level will be a predictive metric is if the the same circumstances occur exactly the same way the next time. Estimation is just that. It is not predictive in nature, it is a best guess based on the knowledge known at the time. And before anyone says it, you can make a better estimate by reducing the unknowns but you can never eliminate the unknowns.

If I have a headache,  I had road rage on the drive in,  I had more meetings than normal, I volunteered to help someone, I was tired …  A whole lot of things could impact the differences between my estimation and delivery.  So in my “estimation”, this metric is a “narcotic metric”, it tends to make you feel good but it actually could be very damaging when using it.

And what if we do know this information? The key is to be able to take information learned and make it actionable. How do we do that? Send an email and tell the team to estimate better? Begin to question their estimates? Make them sign off? I cannot see how you “use” this information to help them actionably improve.

Refinement Metrics

One type of metric I always recommended for consideration is one I consider a refinement metric. This type of metric is designed to allow the team to perform self-reflection on a recent event given the context of more knowledge and apply that knowledge to a past decision. Instead of comparing the past to the outcome, it asks “given the things we learned, do we think we made an accurate assessment of the work”? Sounds similar but with a couple of differences. 1) It’s never at a task level. 2) It’s a team level rather than a individual developer level as the goal is that the team learns to become better as a team, not as just an individual member.

So what I suggested is something we would often do as part of a retrospective with a team. We would examine the stories for the sprint just delivered and look at the assigned story points. Then we would have a discussion and asked if given the knowledge today, would we apply the same story points. This typically leads to a discussion of dependencies, issues, etc and the team centers pretty quickly around a “stand/raise/lower”. This does not help them get better in defining the individual number itself but helps them reflect on this type of work and the hidden complexities that can be present to determine questions that they may ask themselves or the product owner to create a better consensus around an item in the future to the potential complexity of the work.

Just in Time Metrics

One metric that I have read about after working as a scrum master that I liked was a daily vote of confidence. If you have ever been in a U.S. hospital and had surgery there is a common tool used by nursing staff to determine the level of pain you are in to report and administer treatment. It is called the “pain assessment tool” often and looks like this:

pain-scale-chart

This allows the patient to quickly indicate the level of pain that they are perceiving and reflect this to the nurse, doctor, etc. The blog post I had read (which I wish I could recall the link) suggested using a similar scale for each team member to allow them to forecast their confidence level to meet the current sprint commitment. This allows each team member to express their confidence on a similar scale from “Yep, we rock!” to “Hey guys, I am really, really worried where we are right now” so conversations can be had to determine what’s going on for the purposes of communication at the first responsible moment or to allow the team to swarm around and issue, etc. A simplified version of this has been used by teams that involved “Roman voting” (thumb up affirmation, thumb down condemnation) as well. This type of metric gives you perception of the current state of work in a very real form and let’s you make it actionable. This is often easier to use than seeing potential patterns within a sprint burndown (which is another post).

So just as I asked this scrum master, I ask all of you. Do you have metrics? Who are they created for? Are they actionable or are they just data? How do you use them? Are they actually helping you and even more important are they bringing value back to your team(s)? How do you know?

I leave you with a quote about the importance of knowing why you are actually measuring something …

“Remember, what gets measured; gets managed” – Peter Drucker

Let me tell you a story …

“It’s like everyone tells a story about themselves inside their own head. Always. All the time. That story makes you what you are. We build ourselves out of that story.” – Patrick Rothfuss, Author

 

How did it all start?

My journey started with a personal quest to transform the way I work and delivered value. I was deeply embedded inside a V-model culture in which the end result not meeting customer expectations was typically blamed on the customer.

I started my journey by annoying my manager to allow me to create a pilot project (of little significance to appease me) for my organization after reading about the scrum framework. I knew that this was going to be the wave of how organizations began to work and saw a clear path as to how it could benefit the government sector. So I prepared, I studied, I learned, I asked questions and became immersed in how this worked.

I was given a small team of what I will call “the usual suspects” which were made up of long term employees who were pretty adverse or afraid of change, an assigned “product owner” (who they decided a project manager fit the bill) and a stakeholder who had no idea what I was trying to do. My goal had been stated to conduct this pilot and deliver my findings on if it could benefit this public government organization and what type of staff would be needed to sustain it. So here I was, new team, no idea what this crazy person indicating he was a scrum master (with no experience) asking them to work in a new way in which they would drive their own work, a product owner who needed to understand the role and learn to “lead a team without authority”. This seemed like a real challenge. So, I was all in.

How I got started with my first team …

I started by gathering this new team together and explaining very simply the framework, the roles and rituals and how sprint cycles worked. I was met by questions such as:

  1. What do you expect us to be able to deliver in 2-4 weeks?
  2. Where are the requirements?
  3. How will I test an application without requirements?
  4. You want us to sit together and work collaboratively? What about my cubicle?
  5. What do you mean we determine the amount of work we will deliver? Who manages the project?

And many, many more. I addressed each question as best as I could, remained confident and worked to gain their trust. I assured them that I would be right there with them and help them work through any problems as they arose. I assured the product owner that I would work directly with him to become “team ready” so that he could build his product.

Everyone left the meeting unsure of what lie in front of them.

The initial process …

Needless to say, it was tough the first few sprints. I had to guide the team to understand what “potentially releasable” meant. I had to teach a project manager an entirely new set of skills and way of working and how to establish trust in his team to turn his needs into product without use of command and control. I had to reassure stakeholders as they saw partial software being built out along the way. I had to teach a team, how to conduct a daily stand-up, use a task board and burndown hours. I spent countless hours coaching nervous team members who were so far from the way they worked that they were doing this amazing thing that had never been done before.

Although there was a lot of fear over how they were working, through coaching and support they began to move as a team.

The end result and learning

In the end, the product delivered was a success. It was not that it was a highly prized award winning software package that carried the value that we would have liked but it lit a small spark for some people as to a new way to work.

This team had learned to work together, enjoyed the work they were doing and felt in control of delivery once they found their rhythm as a team. The newly anointed product owner saw benefit in the way he worked in this situation and began asking me how he could “be more agile” in what he did. The stakeholders were happy with the end result and the software was delivered in weeks instead of months.

So, I sat down and typed up a summary of the experience, the overall process and how it shifted roles and needs within the organization, an estimation on what type and level of staff would be needed as well as a recommendation to start small and grow over time as opposed to a large scale shift.

The report was presented to the director of the organization who summarily dismissed the approach indicating “we are never going to do this” (firmly believed in the waterfall approach). I think he may have even thrown it in the trash.

Although disheartened, I knew that this was the right thing to do, especially within the government sector to bring more value through focused iterative work. So, I began to plan my exit from the organization in search of somewhere that I could actually make a difference.

The Partnership …

Coming off of this pilot project and more determined than ever to see this way of working take a foothold. Some leadership shifts had begun to occur and I knew of one other individual within my group that seemed to work slightly differently than the standard PMO. His background was in product management and he treated his product in a different manner than the other project managers. So I approached him and told him about the framework and said “I think you should look at this, you are doing about 80% of it now. You just need the discipline of the other 20%”. He read through it and was intrigued but struggled to get through the scrum guide as it felt like it was more engineering focused. I referred him to the agile manifesto upon which it was built and these values had a much more resonating effect. He became curious. He was a marketer and I had a vision for working in a better way. We were the perfect storm brewing.

As we were both ready for the next challenge, we created a skunkworks project with a new assistant director sanction. We created a team room and sat about to deliver the first product of larger business need using scrum. My new product owner new of a 109 page report delivered to the Commissioner that outlined business related projects (both in planning and “in flight”), their timelines, their progress, etc. It was in an effort to support his regular visits with community leaders with a group of organizational leaders so that he could hold conversations about items specific to the area and be aware of current status as he held the conversations. This report, we later found, had never been looked at by him.

My product owner had the idea that we should produce an interactive map application that could be used on a mobile device so that executives could review this status anywhere and use location as a way to get to these items prior to meeting without going through the hoops of asking a cadre of other people to compile and sanitize the data. I believed that domain data should remain where it lives and that this application should be decoupled from these core business systems yet reflect real-time changes to the data. This had been the debate for many years within unsuccessful committee after committee of how you “connect” the information into a  unified view always resulting in “it cannot be done” or using mechanisms to scrape data from one system to make it visible to another. The problems were:

  1. Once scraped, the ownership of the data in question became transferred to the new owner who was unlikely the owner, therefore would not recognize errors within that domain or ensure that it was accurate.
  2. This was something that actually forced a cross organizational work effort within the business and a base level understanding of owners and consumers of data.

Our theory was through the building of this application we could do several things:

  1. Eliminate a 109 page report that people rarely looked at.
  2. Create a locational context to the data making it more meaningful
  3. Solve a long standing business issue into connecting multiple domain sets of data and giving them visibility.
  4. Create a lightweight tool that since it did not create data but use the data at rest, would allow for quality control in terms of how the data was actually reflected.

So my experience of all of a few months and my colleague of zero months sat about to do the impossible at the time. Create a product (which was not the term used, it was always project in our world coupled with plans, committees, governance, etc) built using the agile framework of scrum with a small but motivated rag tag bunch of team members wanting to do something different and believing they could bring value to the organization. Sounds like a tall order. It probably was. But why was it a good choice?

  1. The product we chose had immediate business value and visibility to the highest level of leadership. It could be a product they would actually use.
  2. It solved organizational problems by connecting disparate data sets and visualizing them in a geospatial context.
  3. It rallied a team. Teams were being demoralized each and every time they worked so hard on a product for many many months just to be told “this is not what we wanted”.
  4. It was focused on value, transparency and visibility. We welcomes anyone to observe how we worked, what we were doing and communicated openly and often. We littered our area with BVCs (big visible charts) indicating who we were building the product for, what the features were and the current progress.

So after putting some solid time into product planning (understanding the need, identifying personas, creating a vision and decomposing high level needs into features) we started with a cross functional team of developers and I played a dual role of scrum master and tester (which I do not recommend of possible). Being cautious, we selected a horizon of 30 days for our first sprint (which probably ran slightly longer as we were learning).

At the end of this cycle, we had a releasable product. Did it do everything wanted? No. Was that the point? Yes.

We demoed the product for the director (who as you recall said we would never do this) who was looking for a win with management. As my PO reviewed the features, the director asked several times “and you built this in a month”? He had no idea that this level of work could be accomplished like this, without the tomes of documentation, the endless committees and death-march approach of a 9 month waterfall effort.

Excited by what he saw and eager to show his leadership value to the executives, he arranged a demo with us and the COO and CFO (even though I am unsure of he understood what had been done or why). Although the first iteration was primitive, they saw the value of this product and method of solution delivery. A rapid innovative solution meeting a business need by people who wanted to respond to change. They immediately scheduled a meeting for us to demo to our commissioner.

Demo day with the Leadership Team

We arrived and setup our demo for the room. We had gone through how we would demo the features and planned to show how it worked across multiple devices so that it could be accessed anywhere. We, perhaps naively, assumed this would be IT, the COO and CFO and Commissioner. The room filled to the seams. Apparently we had stepped on a lot of toes of people who had been promising a solution to this issue for years. They all stopped in to see and, in my opinion, find that one gaping flaw that proved they were right in the impossibility to solve this. Our top leader entered with his staff and off we went.

I produced the 109 page report that this replaced and was immediately struck by the confusion on the commissioner’s face. He had never seen it or if he received it, never read it as it was like a car manual that was designed for the people doing the work, not to help people understand. We continued our demo and I handed him an iPad with the application displayed so he could play with the application and replicate what we were doing on screen. He became more engaged. We were excited and wrapped up the demo for the room.

With a brief pause the commissioner asked “who told you to build this”? We replied “no one, we knew it was an open question that the business had and we wanted to provide value”.

He then proceeded to do what I would call “beat the application with a proverbial baseball bat” telling us all the things it did not do or he wanted it to do. The PO and myself hung on his critique and I scribbled notes so we could process them later. The director looked like we had just shot him in the middle of the room. His perceived “win” seemed to be going south and here were the two guys to blame.

Once the review finished, the commissioner rose and said “I’ve got another meeting but you guys are 100% on track” and left and all of the spectators (many of whom probably felt we got what we deserved) filed out leaving the COO, CFO and IT staff behind. The C level executives apologized for the reaction and the IT director seemed to be disappointed we showed “incomplete software”. But we responded in a way that shocked the room …  “This was great! We now know what he did not like and we can pivot and begin adjusting those features”. We explained that this how this worked. We review regularly with stakeholders, receive their feedback and adjust course as needed. They may have though we were a little nuts. I know a lot of the IT leadership did but with the excitement of the executives, we were given a reprieve to continue.

Within one more 30 day sprint, we had a version that met the needs and it was being used in the field. It was the fastest delivery ever done from a team of 3-4 as opposed to 5-12 over a 9 month period after 9 months of requirements gathering beforehand. We held conversations surrounding value and need, not features.

My PO was made CIO following the success of the product and asked me to stay on and transform the organization to work like this on every product. 4 years later and we have 4 scrum teams, 5 product owners and other pockets of agility. Even our own HR for the organization has become trained in kanban and uses it for their HR projects. The business extrapolated the idea of the scrum team to create “business studios” made up of all of the team members needed to complete a business function for a core business line.

How I planned to Build Something New Here …

When the PO moved into the CIO role he asked me to stay and help him build something new. I agreed under 2 conditions:

  1. I needed to be able to always call BS when I sensed it.
  2. I needed to be trusted and left to build it right.

He agreed (although he may have thought I was a bit nuts, and still may).

First, I knew I could not do this alone. Although I had a significant technical background in all aspects of software delivery, I had to follow the advice of “getting the right people on the bus”. So the initial team for this organization was hand picked and recruited. They were either excited to do something new or brought in superior technical skills and strategy to build out a solid technical architecture. I remained personally involved as a scrum master and tester (as we did not have much depth) and we stayed strictly adherent to the framework (look at the Shu-Ha-Ri principle).

Once I was able to move into more of a leadership role, I set about doing a few things that I think, although small, made a big difference.

  1. This new organization would be align as flat as possible to encourage self-management and self-organization. Everyone reported directly to me to support the people doing the work determining how the work would be done. This did not change until the group had significantly grown and it became necessary to add a layer.
  2. Continuous learning for the group would be core to the values of the new culture. We identified a great online technical education resource which we procured for every staff member and the idea of a “lab day” in which they built upon their own skills following each sprint became standard practice.
  3. The idea of team protection and focus from distraction was also a core principle. We minimized disruptive impact to the focus the teams and encouraged, coached and empowered them to take commitments seriously by ensuring that the people doing the work indicated the commitment of work that could be done.
  4. I hired a couple of eager team oriented scrum masters to be servant leaders to the teams and help them mature.
  5. Ensuring space was available for the team members to innovate and exercise personal creativity. Outside of the standard lab day within the cycle, I self-funded and piloted a hackathon which is growing into a larger and wider event for the broader organization.
  6. Hiring became focused and central to our growth. We broke out of the typical mold of the state process in which an applicant performed a 1 hour interview in which they regurgitated their resume and convinced you to hire them. We implemented 3 hours interviews that combined not only behavioral based questions to gauge how they had responded in the past to situation or might do so as well as a 2 hour technical interview in which the expectation was that they demonstrate the skills needed to do the role for which we were hiring. This has been something we have maintained focus on changed over time as opposed to making it a standard approach. I strictly adhered to the rule of “hiring the right person” and if they did not show up, I hired no one (much to the dismay of my leadership as the public sector hiring process can be cumbersome). I truly believe that this helped us create sustainability by making good hiring decisions.
  7. I placed equal focus and attention to the cultural and technical growth aspects of the group. I hired people that were “culturally additive” in terms of value and with the help of strong technical leaders we defined and adhered to an architecture complete with design patterns, branching and merging strategies and promotional process. Defining this initially but leaving it to the technical people to grow has done well. I tried to be very intentional to create some growth paths by not hiring for every position so that people felt they had to leave to get ahead.
  8. Instead of overloading a lot of processes (outside of the rules that were outside my control in the public sector) I imposed a litmus test for decision making composed of (2) key elements of consideration. Is what we are seeking to do “reasonable and responsible” to ourselves, our team, the citizens, our organization? If it met this litmus test and we understood and accepted the personal responsibility of the risk, remained transparent to those involved or impacted, the people doing the work had the complete freedom and support to make good choices without committees, work groups, management hierarchical approval, etc.
  9. I established the idea of creating tribes within the organization composed of people with a passion to solve a problem that they created themselves and managed. This applied to everything from how we celebrated birthdays to our recurrent staff meeting to process improvements.
  10. Everyone had a voice. Starting with everyone reporting to a single point it was easy to establish that anyone had the right to speak out. I reinforced this to staff by being an advocate for meritocracy, not democracy. “Good ideas come from where they come from” was the guiding idea.

In doing all of these things, I learned a lot. I challenged a lot of preconceived ideas of how people operations worked and how work got done. I have to say, although there is always room to improve and grow, I am very proud of the teams that are here today. I have had a few people move to new opportunities (always in a positive way) and seed groups of their own or seek to take aspects of the culture and apply it to new organizations.

While I have always hated to see people leave, I treated this as a good thing that they were growing and not dwelled on any gaps it left behind, which I think has been encouraging to them and not created undue organizational stress. So many public sectors operate in fear of “that one guy” leaving as they carry so much legacy knowledge. They do not stop to realize the problems is in the silo of knowledge as allowed by the organization, not the person themselves.

So why did I share this journey?

Some might think it is for the purpose of braggadocio. Nope. While I am proud of where I am and where this organization has grown, I see miles of potential unrealized before us. I think we are where we need to be today and hope we continuously inspect and adapt to get us where we need to go to become truly high performing.

I have heard many stories that amaze me on how people shaped their work world and I take personal pride in what I do and am impressed by the strides of many others. I have tried experiments that have succeeded and some that have failed miserably. I am very fortunate to be in an environment that has allowed me to do this as they know that I am aware of risk without sacrificing the need to experimentation. I truly am grateful for this opportunity.

Personally, I am grateful for everyone I work with from the most agile person within the organization to the person that is struggling just to figure out how they fit in the agile space. The former because they focus on value as a driver in the way they work and the latter because they want to learn, adapt and grow most likely or find the way they can connect with something different.

I take pride each and every day knowing my teams are in control of the work they do, take their commitments seriously and work to deliver quality products to the best of their ability. I take pride in seeing the depth of people we have and how those differences make them a more solid team as a whole. I am humbled by the fact that a great deal of people took a chance to try something different and trusted that we were building something great. I take pride in building an organization in which and every person has a voice in their work no matter their role and that teams are protected when they fail from being vilified and  are asked to use these as learning opportunities. I am proud that my teams know the value of the “first responsible moment” when encountering problems and raise the flag to draw the attention when it happens so that risk is managed in real-time as opposed to being based on a risk register outlining risks that may or may not ever occur.

I spoke at an agile leadership summit about 6 months ago and one of the other speakers said “you should tell stories more, you have a knack for it” (unsure I agreed but appreciated the compliment). I actually did tell the organizer that if they had a rocking chair available, that is was best not to place it where I could sit when giving my talk or I might keep folks for a while. Yes, I love to share things with others. Perhaps it is in my nature and wired within my regional DNA in general.

The reason I share  and this story is that I want people who may be struggling with a transformation or even just getting started to have hope.

Hope that you personally can do something different and affect change. I helped drive the implementation of agility in the most unlikely of places at a time when “death marches” of project failure were accepted in the culture as the standard practice of work and the value add by IT in general was viewed as very low by the business. From this small product, we transformed an organization and a culture and started a broader conversation that continues today. I often tell people when I started this conversation, I was the only person in the room (which meant a lot of talking to myself). I recently attended a meeting where 10 people engaged in a conversation of how to apply agile conversations more broadly and have coached, mentored and shared this story with a lot of folks over the years.

I alway recall a quote that inspired me early on from Mike Cohn.

“Agility is not something you become. It is something you become more of …”

If you’re stuck now or things are less than optimal. Stop. Take a breath. Figure out where you can pivot and where you can persevere. If you are unsure where to start, find that thing that you can make valuable and start “starting”. Be as agile as you are able to be given constraints and then push to become more agile. Learn from failure, embrace feedback, push yourself and do not compromise or collapse in the face of adversity. Show people a new way to work and build a culture that drives to empower and trust those doing the work, not operating under command and control.

I am going to end this quote with a passage from Apple’s “crazy ones” ad campaign created by Rob Siltanen and hope you all stay agile!

“Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently.

They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things.

They push the human race forward. And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.”