Tag: team

Continuous Improvement

Thinking about continuous improvement the other day I tried to figure out what makes a continuous improvement process work and what makes it stick, these are my thoughts:

  • It should be a slow, gradual process of change, no “sudden movements”.
  • It should be a continuous flow of change, no settling down into a rut.
  • It should be a culture, not a bunch of individuals with ideas.
  • It should be unanimously accepted.
  • It should be measurable.
  • It should be celebrated.
  • It should be evangelized.
  • There should be room for failure, and for success.
  • It should be rewarded.
  • It should be encouraged.
  • It should become default behaviour.
  • It should be transparent.

What else?

 

A great team

For me agile is about many things but first and foremost it is about people and dynamics between people, you get the right recipe going and anything is possible. I work with what I think is a great team, but what makes them a great team? I’m not entirely sure but here are some of my ideas of traits of a great team (in no particular order):

  • There’s a good level of respect not only for each other as people, but in each other’s ability to do stuff.
  • They trust each other.
  • The team has built in redundancy so anyone can take time off at any time, no silo’d experts.
  • There’s lots of laughter and healthy tomfoolery, they know when to work, but they also know when to play (at work!).
  • They allow failure and learn from it,  focusing on the problem, not the person.
  • High levels of collaboration, both at work and at play. They help each other out constantly, no-one is ever “too busy” to help.
  • They’re cross functional, there’s a good mix of skills amongst the team, helping with redundancy.
  • Everyone feels they can talk openly about issues and problems.
  • There is no fear (of failure, of specific people), they take chances and enjoy challenges.
  • They self organize, there is no one leader, they all lead, they all follow.

There’s more I’m sure, but those are the ones I can think of right now. At the core of it I think people must feel like they belong, that they are respected for their skills and trusted with responsibility and above all treated like people, not resources.

Thoughts?

Star Trek, a model for Agility

As a Trekkie I’m prone to watching reruns of old Star Trek episodes from time to time and I started seeing many similarities between an agile approach to “getting things done” and the way the crew of the Enterprise work. Yes, granted, it’s a militaristic structure but that’s not to say you can’t still be agile:

  • Crew members exhibit a general knowledge of most fields, with expertise in a particular field (see how well the bridge crew interchange roles during disaster situations where members go down).
  • Away teams are generally cross functional based on the task at hand, and usually range in size from 3 to 7.
  • The Captain issues orders (“what”) but relies on the crew member(s) to execute them (“how”), and does not interfere unless further clarity is needed.
  • There is a deep level of trust and respect between crew members.
  • There is constant collaboration, communication channels are constantly open from anywhere on the ship (and off).
  • They celebrate their victories and learn from their mistakes, and adapt as needed.
  • At any point in time, the crew is working on whatever will add the most “value” to the mission (work is prioritized).
  • There is an understanding that collaborative teamwork is the way to success.
  • There is a good work/life balance, even on a Starship.
  • The crew are passionate about their roles.
  • Mission planning sessions only plan enough to get the mission going, and are then adapted on the way.

Any other Trekkies out there see similarities I’ve missed?

Change is good

I’m often amazed at the number of dogmatic “prophets” out there when it comes to the latest fad’s of agile development. I myself am about getting productive and like to take the best of ALL worlds; change is not only inevitable but necessary, even changing of a process BUT, only if the change leads to improvement! I believe a process of continual introspection and change by a team, combined with a good way of measuring the effect of that change,  is essential for good team performance.

That in mind we made the following changes to the way we practice scrum:

  1. We added a default story to cover recovering technical debt (or refactoring if you will) in that story. Essentially we assign a “story point cap” to this story (say 5 points) that’s based on our current velocity and duration of sprint. We then assign “technical debt recovery” tasks to this story until the team feels there are enough tasks to fill the story points. I know, sounds like the wagon pushing the horse but it’s something we’re trying that other teams have used effectively.
  2. We’ve started estimating (wait for it…) HOURS on tasks. Stories are still broken into story points but the tasks are estimated in “hour blocks” (2, 4, 8, 16) as they are put up. The purpose of this is to act as a type of “sanity check” for story point estimation. An added benefit I found was that the team members seemed to think a lot more about a task when they had to assign time to it.
  3. We’ve started using a round table instead of the tradition square meeting tables. I found this very effective in encouraging participation and collaboration.
  4. Story point estimation was done using a technique I learned on training that speeds up the estimation incredibly (works well with lots of stories). This is how it works (well, how we did it anyway):
    1. All the stories are explained to the team and placed in a pile on the table.
    2. A wall/board is divided into sections, each representing a story amount (we used 1, 3, 5, 8, 13, 20, 40, 100).
    3. Each team member takes a pile of cards and sticks them in the column(s) they believe it belongs, no-one talks or interacts other than with the product owner to understand the story further.
    4. If a team member disagrees with where a card is, he/she simply moves it to where he believes it SHOULD be.
    5. This carries on until all the tasks are done. Remember, the key is NO COMMUNICATION between team members during this process, this has the effect of forcing people to think about why someone made a decision to place something in a particular column, or why they’re moving it.
  5. We’ve started experimenting with TDD and Paired Programming, which seems to be going well.

One additional thing I’m toying with is moving to a more Kanban based board, the team has problems with taking on too much work and I think creating a way of limiting the pulling of work will work.

Finally on how to measure if these changes are effective, well, to be honest I’m not entirely sure. I think the best way is simply to see if the team becomes better at actually doing what they predict they can do while maintaining a sustainable pace and having fun; other than that I guess we wait and see…

I’d be interested to know what kind of changes you brought about in your team and the effect of them (both good and bad), let me know…

The chatty daily standup…

One of the “ceremonies” of Scrum (man that sounds so culty) is the “Daily Standup”, a daily planning meeting where teams realign and coordinate their efforts for the upcoming day. It’s a concise, no frills no fluff zero waste of time meeting that answers three questions: what have I done, what am I doing and what are my issues, and is generally over quite quickly…but what if it isn’t, what if it degenerates into a technical discussion about the implementation of widget-x or how the build script is not building something correctly or which framework to use to solve some problem…

I’ve found this to happen quite often and all too often I see people coming down on the team with statements like “cut the meeting off at 15 min” and “remind the team to stick to the 3 questions”… all good advice but you’re fixing the wrong problem. I believe this behavior to be an indicator of a dysfunction within the team itself. In a truly collaborative environment teams should be discussing and solving problems constantly and not just at certain points through the sprint (like the daily stand up). If they’re only collaborating around the daily stand up then something is wrong and the team has a dysfunction preventing constant collaboration…

My questions on agile processes

Something I have found very interesting in today’s “agile environments” is the adoption of processes.

I’m caught in an endless loop on my thoughts around the place of processes and how they should fit in a team.

Generally processes are put in place in order to protect the team, sort of like a safety net.  Given this chain of thought people should be interested in following the process, and should try following processes as close as possible. At the end of the day, Its almost like wearing a safety belt.

This is where it gets tricky though, in many cases developers, testers or any other team members may not not see the need for this process, they may believe it is more of an impediment than anything else.

How should this be dealt with ?

Should the team be wholly responsible for the decision to keep or lose the process ?

Should the team be educated every time a process is put in place ? ( Its too often I have noticed that people simply follow processes mindlessly)

In true scrum nature it suggests that the team make these decisions. What if some of these processes have been put in place by parties outside of the team ? Furthermore  these parties that may have a good understanding for the need of the processes ?

So I go back to my safety belt analogy, sure its a pain to put it on, but if you are unlucky enough to be involved in an accident I can assure you that you will wish you had been wearing it. Unfortunately in scenarios like this it seems its only when its to late when one may value the process ?

Another question  I have is around how often should the necessity of a process be revisited ? Is agile not about constant improvement, about constantly looking at what went well and what could have been done better ?

Here is my take, but please add comments im really excited to hear other opinions on this…

I believe that  processes should be revisited constantly, possibly with each scrum retrospective, its important to remember when doing this to consider the impact of failing to implemt and follow the process.

If the process is enforced by external party, and you feel that you dont see the need for it, discuss this with the party responsible and try to understand why it is they deem the process necessary, it may turn out that you have already covered the risk that this very process is trying to prevent. After all is this not what scrum is all about ? COMMUNICATION ?

An (agile) environment…

Scrum often talks about “ideal development environments” (Mike Cohn has a nice blog post on this entitled The Ideal Agile Workspace, well worth the read) and this often excludes anything related to engineering (hardware, software etc.), for the obvious reason that Scrum does not profess to offer guidance on engineering practices (but clearly states they are important) but rather on “management” practices.

Anyway, to the point of this post. I have a challenge at my current job in designing a development environment (hardware/software, not physical environment) geared for agile development. I had some high level ideas:

  • Somewhere to play – I figure it’s important for team members to have an area to “play” in, experiment with ideas, test theories, do proof of concept, without it impacting other teams, especially in environments where multiple teams are building toward a common project.
  • Somewhere to build – teams need somewhere to actually construct things, typically this will be their own machine, together with a (decent) source repository to share and control versioning of code. Probably overlaps with their “play” environment.
  • Somewhere to share – Collaborating teams are good teams (if not great teams). Encourage teams to collaborate by not only co-locating members but giving them access to tools to share information (wiki’s, blogs etc).
  • Somewhere to test – Generally I believe there are four “kinds” of testing, integrated into the sprint at various points: developer testing (does my stuff work and have I broken anything), integration testing (does everything works nicely together), quality assurance testing (does everything performs at a predefined “quality” level, this should include, but not be limited to, security, performance, durability etc.) and user acceptance testing (does the product meet the requirements). Each level of testing adds an additional feeling of “warm and fuzzy” and, as such, I believe each of these environments should be clearly separated, demarcated and controlled.
  • Automation – everything that is repetitive should be automated, plain and (maybe not so) simple. There is, however, a small “addendum” to this, in my opinion: The degree of risk determines the degree or automation, the higher the risk, the less the automation. Take for example releasing a product into a production environment, a simple enough task to automate, but can you risk it going pear shaped? I don’t know, am I wrong here? Perhaps this is just a trust/quality thing and if you have enough quality (and confidence) checks in place, releasing to a production environment is a trivial task that CAN be automated?

In line with the above this is what I think would make a good environment:

  • Every team member has his own environment (machine) that is capable or running as much as possible of the required frameworks/tools/databases etc.
  • Where something cannot reasonably be run on a team members machine (think large databases), establish a common “development” environment where a reasonable copy of the system can be run on. Set rules for working on this common environment (typically a team can sort this out amongst themselves). The team has full control of this environment. Possibly virtualize this environment so that it can be backed up/restored/recreated/duplicated easily.
  • Create a shared environment where team members can collaborate ideas, a wiki and a blog are good ideas, hell, even a twitter like setup might be interesting, of course this should not be used by management to track progress!
  • Create a source control environment with a high degree of stability (backups etc) and control. Define solid rules for using this system, retroactively “fixing” a source control system is a nightmare. Some good ideas for versioning/branching can be found here (specifically for CVS, but the concepts can be applied to any decent version control
  • Create an integration environment that is a closer match to the production environment, automate the building of systems to this machine on a continuous basis, giving feedback to team members (via emails/web pages etc). This is the first “gate of quality” for the work being produced. This environment should be automated as much as possible (if not completely), again consider virtualizing for the same reasons as the development environment. Consider this a “sanity check” environment to make sure everyones contributions “play nicely” together. This environment can run all the testing frameworks (although consider also running on the development environment?):
    • Unit testing (and test coverage testing)
    • Code style checking etc.
  • Create a quality assurance environment that near perfectly matches your production environment. Work is automatically “promoted” to this environment if it has succesfully passed all the integration quality requirements. Consider doing functional and non-functional tests (performance, security etc) here (although the integration environment is also a good candidate for this, but the quality assurance environment should be a closer “replica” of production, so more than likely will behave similar to it). This is where team testers will “see” the results of the team, it should be treated similar to a production environment and accorded the same level of “respect”. Members of the team that are doing the physical development must consider this environment as “production”. Remember also to “automate what you repeat” at this point, tests that are run on the system should be automated as much as possible. This is the second “gate of quality” for the work being produced
  • Create a user acceptance environment where business will ultimately see and comment on work done. This is the final “gate of quality” for the work being produced. This environment should be treated EXACTLY like the production environment and code should only be “promoted” to this system, not built. After business accepts on here, the code is “release ready”. Consider automating the process of releasing code to this environment, if possible, however the types and degree of testing that needs to be run on QA in order to promote it to this environment may prevent it.
  • Finally, of course, production environment… but that’s a whole different kettle of fish and I’ll leave that up to more qualified people to build 🙂

Ok, so those are my (perhaps random) thoughts on the subject. Have I left stuff out? Sure, I probably have. Will this work practically? Not sure, I think it should, I’m going to give it a try. Is it “agile enough”? Who cares, it can evolve, change. I think it can work though, with enough automation and enough discipline it should be a decent solution.

I welcome any (constructive) opinions.

It’s about people…

“Individuals and interactions over processes and tools”

I’ve been thinking recently on the importance of people in this whole agile “thing” (for lack of a better word). I think people lose focus of the actual PEOPLE in a team and still focus on them as resources (some nice baggage from our waterfall days). Agile pushes the concept of a team thinking and working as a unit but I think it’s easy for individuals to become “lost” in this team and forgotten. Don’t get me wrong, I agree on the “team” mentality but people should also not forget about the individuals making up the team.

A simple question, as a “leader” of a team (ScrumMaster etc..) when last have you actually tried to find out if everyone is still “happy”? When last have you interacted with the person as a person and not a resource? I think, to some degree, personal interaction is important. Take a ScrumMaster for example; one of the key things they should be doing is “removing impediments”; often people think of these as purely work centric issues but what if they’re not? What if a team member is experiencing personal issues? This will definitely have an effect on the velocity of the project so why should you not try to help (or at least be aware of it)?

I guess what I’m saying is do not depersonalize the team, reducing them to “agile resources”; make people feel like they’re not only part of a team, but that they’re an indispensable individual within that team…

A new challenge…

Today is my 3rd day as an official ScrumMaster. Although the first 2 days were, well, daunting at best, today there seems to be a bit more clarity. The challenges here are similar, but still different. Resistance to adoption is coming from a different place this time. The teams seem to want to do Scrum (at least it appears that way), although there is ALOT of area for improvement. There is some frustration from management and this is starting to flow over into the teams and cause people to disbelieve the effectiveness of an agile approach (I guess it’s a classis “blame the tool” scenario). I think the frustration comes from the misdirection that exists in the way the teams are applying Scrum. Off the top of my head and based on a few days of observation the following are big issues that need to be addressed:

  • There is no visible prioritized product backlog with no obvious release plan (I believe this is where the main frustration comes from)
  • The teams have no burn down charts, they seem to be relying on the tool (Version One) for this, but without the discipline of keeping it up to date, it’s not really useful. Another reason why I don’t really like tools, people place too much reliance on it and fail to realize that it’s not using the tool that’s important but rather that something actually gets done.
  • There is a need (and lack of) a Scrum of Scrums to co-ordinate the effort between the teams.
  • The daily stand-ups are not focused co-ordination meetings and often break down into general discussions, sometimes “chickens” even take control of the show.
  • The impediment lists aren’t being managed (and aren’t prioritized)

There are other smaller places of possible improvement, but we will need to fix the larger issues first.

Overall I’m a mixture of excited, confused and nervous about the next few days. Where I had the advantage of already having earned the respect of the previous companies team I now find myself sitting with the the daunting task of having to re-earn respect. I do not believe in telling people what to do but rather in having them do things because they feel it is the right thing to do, for that to happen people have to respect you and your opinion and believe in you. Until that comes I will fall back to process and hopefully the respect will come when my opinion creates value for the team(s).

Let’s see how things go…

Change…

The new year will bring a plethora of change in my life, a new company, new goals, new challenges, new ideas. I must admit I’m eagerly looking forward to this much like a new astronaut looks forward to his first space flight, nervous excitement I guess would summarize it.

Along with this I’m also a little sad about leaving my current employer. I’ve been instrumental in growing Scrum to where it is at the moment and I have to say that, although there is still alot of room for improvement, it’s just reaching a point of “proving itself” and getting it’s feet, and now I’m leaving. Lets hope the passion I tried to push it with rubbed off and that it will continue to improve on itself and a new champion will step up to fill the gap. The team(s) I worked with have reached a point now where they are reasonably self organized, so there will be no problem there. I think the possible impediments to continued growth of Scrum will be:

  • The lack of a strong ScrumMaster/Coach to protect the team(s) and nurture the process.
  • Inteference from management due to “command and control” culture.
  • Breakup of the existing team(s). Although this may prove useful because they may end up “infusing” the other team members.
  • The warping of the process in order to hide problems.

I’ll have to come around here in a few months to see how things are running…