• Home
  • Training
  • Coaching
  • Tool Box
    • Tools
    • Working Remote Resources
  • Events
    • Webinars
  • About
    • Join Our Team
  • Contact
    • 317 (983-2459)
  • Log in

January 5, 2018 by Chris Daily Leave a Comment

Career Path: Scrum Master -> Management

A few weekends ago, I conducted my first Management 3.0 #Workout class.  Intentionally, it was a small group that I hoped would be open to the concept.  The class went well, and I got some great feedback.  Management is one of the few roles that there doesn’t seem to be a formal certification or process that signifies one know’s what to do.  A management degree (MBA or Bachelors) can teach the basic skills of marketing, accounting, and operations, but doesn’t teach you the skills that you truly need.  Skills such as servant leadership, communication skills, problem solving, and dealing with conflict.

I had a few moments the other day, and I started thinking about what attributes were possessed by some of the great managers I have worked for in the past.

One of the questions that I created for Pocket Prof  revolved around the concept that “Scrum Master” is a management role. The correct answer for the certification is True. I have yet to see this as a requirement in a management job description though. What would happen if were to become a requirement? I think most of the managers I know would put up fight on this one. Heck, I would put up a fight before I understood what the attributes of being a Scrum Master.

I went back to the beLithe Scrum training deck and took at look at the attributes of a Scrum Master.  All the attributes would be ones I would consider important for managers to possess as well as Scrum Masters.

Let’s take a look at the attributes and consider whether they apply to a management role.

  • Agile Expert – Expert may be too strong, but managers should be searching for tools, practices, and frameworks that can be introduced as required.  Topics such as DevOps, Extreme Programming, Test Driven Development, and Automated testing are foundational concepts that should be known and explored by every manager.   Being familiar with Scrum, Kansan, and Lean are important.

  • Servant Leadership – People who do the actually work are the ones who actually create value. Management’s responsibility is to create an environment where people can do the work. By adopting Servant Leadership, managers serve the people who do work by removing impediments and enabling them to do the work.  The term manager should be replaced by Servant Leader.  Terms such as manager or team lead have been damaged by overuse.

  • Communicator – Most of the challenges with teams and organization is a lack of communication.  Managers should be effective communicators with their peers, customers, with their teammates, and with others in the organization. Manages that can’t communicate are ineffective, yet somehow continue to be managers.

  • Facilitator – For years, traditional managers would plan the work, assign the work, and then evaluate their direct reports. Recently, great managers have transitioned from hierarchical control to a facilitated self-organization approach. Self-organization requires trust. Managers have to trust their teams, and their teams have to trust their managers that the environment is safe.

  • Worthy of Trust – Being worthy of trust is the most important characteristic a manager can possess. If a team trusts that a manager’s intentions are honorable, the team will be tolerant of mistakes, and allow the manager time to learn.  A manager without the trust of her team will never be a leader, but will be directing/dictating.

  • Coach – The primary job of the manager is to coach teams and individuals. As a coach, a manager has to understand what to do, why it needs to be done, and what the benefits and risks are. Combining coach with being an effective communicator allows management to change communication styles to ensure that each team receive.

These traits are vital to transforming an average manager to a skilled and effective leader. So why am I saying that the Scrum master role would be a great addition as a step to the career path for managers and executives? The Scrum Master role is unique in that, with no direct reporting responsibilities, the Scrum Master can’t rely on the implied threat of power and position. Not being able to rely on technical skills, when stepping from an individual contributor role into the role of Scrum Master encourages the utilization and refinement of other skills.

Most of us tend to fall back on the skills that led to our promotion when we are pressured or stressed.  Many times those skills are a hindrance to us in new opportunities.  In my experience, development managers are great technicians that have expressed an interest in being a manager.  Often, though, they have not had mentoring in the skills required for the next level of responsibility.  The Scrum Master role is a great way for the manager want-a-be refine those skills.  What do you think?

Thanks for coming in today.

Chris

Filed Under: agile, Leadership, Scrum Tagged With: agile, Leadership, management, software development

June 23, 2015 by Chris Daily Leave a Comment

“Managing” Software Development – The Daily Standup

If you have been around software development at all, you have probably attended a “standup” meeting.  So why, is this meeting so important?  This meeting provides at least one opportunity for teammates to communicate with each other on a daily basis.  I recommend three components for the meeting to be effective:

  • The meeting should be recurring daily.
  • Everyone who is physically able should stand for the entire meeting.
  • The purpose of the meeting is to communicate a micros status of each teammate’s progress.
  • The meeting should be brief, and limited to 15 minutes or less.
  • One member of the team should facilitate the meeting.
  • Anyone can attend the daily stand up, but only the team members may speak during the actual meeting.
  • Discussion during the meeting is limited to each teammate answering the following questions:
    • What did I do yesterday?
    • What did am I going to do today?
    • What are the things(roadblocks) that stop me from getting my tasks completed?
  • Any detailed conversations should be wait until after the meeting is over.

Simple and to the point, daily stand ups in this format create a number of positive outcomes.  Each teammate providing the answer to the three questions daily provides each member of the team an opportunity to let everyone else know they completed a task.  Getting stuff done will become infectious to a team.  Those teammates that are struggling will report the same thing several days in row, which create a small coaching opportunity.  More times than not, the team itself jump in and attempt to help teammate.  These coaching opportunities serve as a timely feedback loop to respective teammate.  Without the daily stand up, those feedback loops often manifest themselves in the yearly performance review, with decaying performance and coaching feedback.   Unfortunately, some teammates are not suited for their role or the company, won’t like the exposure of reporting a micro status, and will self-select themselves out of the team or the company.

Meeting on a daily basis will help ensure the updates are small in nature.  Everyone having to stand will also help keep the meeting short, as most people don’t like standing in the same spot for more than 15 minutes.

There are all kinds of reasons on why roadblocks are encountered.  The roadblocks often start out small, but have a tendency to grow into huge mountains over time.  There also many types of roadblocks which can become visible.  Some roadblocks are easily removed by the team, while other roadblocks require help to get removed by someone outside the team.  This is an opportunity for the servant leader/facilitator to help.  By learning about roadblocks early, the roadblock can often be addressed before it becomes larger and more complicated.  If the roadblock is bigger or more complicated than the team can handle, the servant leader has the responsibility to find an acceptable resolution or mitigation.  The effects of the roadblock can be communicated quickly so appropriate expectations can be set.

The daily stand ups often become a ritual, and are utilized by those outside the team.  In addition to listening to the daily micro status, non-team members who have questions quickly learn that, right after the daily stand up, they can ask questions and provide feedback to the team.  In person verbal feedback is far more effective than an email.

One word of caution:  stand up meetings have to stick to this format or human nature will turn this into an much longer time commitment with the benefits and value decaying over time.

Daily stand up meetings are effective regardless of the type of team you are on.  I have seen them used in lots of different types of teams, including customer service, marketing, sales, management, and operational teams.  If you are “managing” a team, start with the daily stand up.  Your teammates will grumble, groan, show up late, and generally try to avoid the meeting.  After a few weeks, your teammates will start to see the results.

Thanks for coming in today.

Chris

Note:  This post was also posted at belithe.com.

Filed Under: Agile, Blog, Business Musings, IMO, Scrum, Software Development Tagged With: daily standup, management, scrum, software development

June 8, 2015 by Chris Daily Leave a Comment

“Managing” Software Development – Servant Leadership

This is the second post in a series of posts under the topic of “Managing” Software Development.  If you haven’t read the first post, you probably should start there by clicking here and reading that post.

For those of you that have read the first post, welcome back.

Don’t tell anyone, but I really don’t “manage” software development teams.  I spent my formative years early in my career working at a mid-size bank.  Hiearchical management practices and organizations were all the rage.  I wanted to be the “boss“.  I wanted my “people” to do what I told them because I said so.  I knew what needed to be done.  After all, I had two years of experience and a bachelor degree from Ball State.  By now, you can probably guess I had a rude awakening coming!

My first team was made up of mostly folks who had less experience than I did, and were rebellious, independent, and a heck of a lot smarter than I was.  Trouble was coming, and I didn’t have a clue.  I will never forget how shocked I was when I showed up for a meeting with Paul McGinnis and Dan Lehman.  My entire team was waiting on me.  My memory of the meeting was the team was patient, but yet firm in telling me that I was screwing up.  I was sucking the enjoyment out of their jobs, and they weren’t happy about it.  I walked away with one key point:  My team could have ambushed me, but was still with me and needed me to do what they could not.

At the time, I didn’t have a clue about servant leadership, or what it was.  I knew that I was going to fail as a manager if I kept “managing”.  I knew that a group of people could get more done than an individual, but how did I get this group of people to do what I wanted?  How do I control them?  After all, I was working on an MBA.  I knew it all!  I should be able to do this.  Hiearchial management had been working for 70 years.  The industrial age and the modern assembly line made quotes like “Why is it every time I ask for a pair of hands, they come with a brain attached?” seem accurate.  All that was needed was an employee who wouldn’t think, but would do exactly the same thing over and over.  I thought managing software development was just telling developers what to do, and then kicking back and relaxing.

I didn’t realize it at that time, but my team was telling me that control is an illusion, and that I needed to be a servant leader.

What is Servant Leadership?  Robert K. Greenleaf defines Servant Leadership as “The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead.”  How can you lead if you are a servant first?  I got lucky.  My team jolted me into a servant leadership style management without even understanding what it was.  My team wanted me to switch my approach, enabling them to do their job.  The team knew how to write code and had a great knowledge of the systems that we were charged with maintaining.  The team wanted me to provide overall direction, and get rid of anything that kept them from doing their job.  That’s what I did.  I bought them donuts occasionally, respected them as professionals, and protected them from everything else.  It worked.  They didn’t quit on me, and I started serving them.

Over the years, my teammates at various stops have continued to reinforce that Servant Leadership is the right approach for me.  As an avid reader, I have found several excellent Servan Leadership references that have reinforced the approach.  I have found that most teams have evolved into a state of dysfunction, not because of the members of the team, but because the “manager” of the team doesn’t get Servant Leadership.  Those managers set the bar so low, that being a servant leader has an immediate impact on the team dynamics.  Often, being a Servant Leader is all that is required to turn a team around.

Servant Leadership has certainly changed my career, providing me a fulfilling career, with some great friends and even greater memories.

Thanks for coming in today.

Chris

Filed Under: Agile, Branding Yourself, Business Musings, IMO, Leadership, Scrum, Software Development Tagged With: development, Leadership, management, software business, software development, Solutions

June 6, 2015 by Chris Daily Leave a Comment

“Managing” Software Development – Not as easy as it looks.

I started a new adventure in January.  I started teaching a class at IUPUI devoted to Systems Analysis and Design.  Over the course of the last few months, I have sprinkled in Agile rants about self-organizing teams, iterative processes, and emergent design with the required object oriented design and UML topics.  Working with members of the class has refreshed my memory on how difficult “managing” software development must seem to the uninitiated..

Why does it seem so difficult?  Here is a brief list that were top of mind without thinking much about it:

  • Most folks don’t understand what it takes to develop great software.
  • Software developers have varying degrees of educational background, skills, and experience.
  • Software developers usually aren’t experts in the functionality of the product.
  • Software built for consumers is different than software built for a company’s own employees.
  • Software built for large companies is different than software for small companies.
  • There are usually at least three different software languages involved in a simple webpage.
  • Software developers abhor testing.
  • Software developers abhor meetings more than they hate testing their code.
  • Software developers tend to be loners, wanting to block out the world by putting on their headphones and getting into a zone.
  • Software developers only respect other software developers.
  • Software developers love donuts.  I do too, so this means I am going to battle my weight the rest of my life.
  • Most managers of software development got the job because they were good developers.

Given all the reasons above, why do I continue to work with software development teams?  There has to be easier jobs out there, right?  I love the job.  I get a rush watching a group of smart people create something.  I would almost describe it as an adrenaline rush.  Not the same adrenaline rush you get from jumping out of a perfectly good airplane with a parachute on your back.  The type of rush when you can’t hardly wait to start at the beginning of each day.  The adrenaline rush created when a group of disorganized, often warring, group of people start getting a huge amount of quality work done faster than they ever have before.  The best part for me is it doesn’t seem like work, and it seems pretty easy once you get the hang of it.

This is the first in a series of posts that will outline how I “manage” development teams.  These posts will ignore the traditional management rhetoric and focus on the some of the uniqueness of managing software development, as well as my approach.  Take a look and give me some feedback.

Thanks for coming in today.

Chris

Filed Under: Agile, Leadership, Software Development Tagged With: development, IMO, Leadership, management, Motivation, software business, software development

UPCOMING EVENTS

Mar
26
Mar 26 : 08:02am EST - Mar 26 : 08:02am EST
Learn More
Mar
26
Mar 26 : 08:02am EST - Mar 26 : 08:02am EST
Learn More
Mar
26
Mar 26 : 08:02am EST - Mar 26 : 08:02am EST
Learn More
Mar
26
Mar 26 : 08:02am EST - Mar 26 : 08:02am EST
Learn More
Mar
26
Mar 26 : 08:02am EST - Mar 26 : 08:02am EST
Learn More

Call Us:

(317) 983-2459

#SLINKYTHINK:
DIRECTLY TO YOUR INBOX

We love Agile. We're obsessed with delivering value to you.

Sign up for insightful thought leadership on people, culture, and Agile. It's what we do.

Footer Form

© COPYRIGHT 2015-2020 BELITHE, LLC · All Rights Reserved · Privacy Policy