Archive
Demonstrating Responsibility
Just about a year ago I attended the Agile 2009 conference in Chicago where I had the opportunity to take part in a half-day workshop with Christopher Avery. It was here that I was first exposed to his Responsibility Process which inspired me to write the post Operating from Above the Line shortly after. I was hoping to run a similar workshop at Point2 to demonstrate Avery’s idea, but I couldn’t garner enough interest from a large enough group to make it worthwhile.
Fast forward a year and coincidentally enough Avery’s Responsibility Process came up as a topic during a staff engagement workshop championed by our Director of Human Resources. As it turned out some of the Responsibility Process posters also started showing up on walls throughout the office, but without context people didn’t know what to think of them.
Following the staff engagement discussion I was approached to run a workshop that would help to demonstrate the Responsibility Process to our Sales, MLS, and Syndication teams. I was very excited to do this and planned to fashion it after Avery’s effective Agile 2009 workshop. It’s easy to get the gist of the Responsibility Process by reading about it, but the true benefit is seeing it in action.
The idea is to get people to work on a difficult task as a group that will likely result in failure, and keep track of behaviour during the exercise. For this particular workshop we had ten people so I split them up into two groups of four. The remaining two were to be my observers.
- The Builders’ Job: build a ten story, free standing structure using only a deck of cards and a small amount of fun tack in fifteen minutes.
- The Observers’ Job: listen to the builders and take notes of any phrases that sounded negative.
Anyone who has tried to build a house of cards probably knows that reaching ten stories is nearly impossible. One group managed to get to seven, while the other group’s unorthodox design proved to be….well, good in theory. But as you guessed the point of the exercise was not to actually build a structurally sound building, but to surface behaviour that fit into the different states of mind on the journey to responsibility.
- Lay Blame
- Justify
- Shame
- Obligation
- Responsibility
Here are some examples of the phrases that were recorded by our observers.
- I already know who’s fault this is.
- We don’t have the right materials
- Someone else do it. I’m too scared to go on.
- We don’t have enough time.
After writing each of the phrases recorded by the observers on a whiteboard I started to explain each of the states of mind of the Responsibility Process. Once everyone had a basic understanding we grouped each phrase into its appropriate state. Some were easy to categorize while others were more difficult which in turn spawned some excellent debate. What I found to be the most beneficial was real life examples brought forward by some as to when they may have been in one of these states recently.
We left the workshop understanding the premise behind Avery’s Responsibility Process, but were aware that this was only the first step. As individuals it is up up to us to make the effort in identifying our states of mind when we encounter conflict, and do what we can to move as quickly as possible to the next level. Now having ten people at Point2 aware of the Responsibility Process, we could lean on each other for support when learning to identify what state we were operating in. And as a company having as many people operating from above the line seems like the responsible thing to do.
The Importance of Clearly Defined High Level Project Estimation
It is safe to say that software development teams work best in the confines of each iteration. All the stories are laid out, estimated, and committed to based on conversations, designs, whiteboard diagrams, and a clear understanding of what is needed to be done. The business team works best in terms of looking at technical projects as a whole as they try to prioritize and decide what work needs to be done to drive business. And this is where the dilemma lies. The business team is looking for a general idea of how long a project will take to complete, but the development team is uncomfortable in providing one until they have all of the stories in front of them. The catch-22 is that stories aren’t written until a project has been given the green light.
The development team’s reluctance in providing high level estimates typically stems from:
- A fear that the estimate they provide will be mistaken as a commitment when it comes time to actually develop the feature/product.
- Not having the chance to fully explore assumptions and risks adds a sense of uneasiness since the estimate is usually heavily based on these assumptions (mainly technical assumptions – business questions should be answered).
- High level estimation meetings can be difficult to facilitate, and can quickly become frustrating for everyone involved. It is very easy to lose track of the goal of the meeting.
At Point2 it is usually the Team Lead/ScrumMaster and a Business Analyst who facilitate these meetings. It is up to them to ensure that the pain-points are alleviated. If the team has a genuine feeling that the high level estimate they provide will be construed as an actual final commitment then there is probably reason for it. Perhaps this was what happened historically and the team is having a hard time getting past that, or maybe it is continuing to happen. If this is the case, as a Team Lead/ScrumMaster it is your responsibility to manage this disconnect. If the nature of the high level estimate is being misunderstood by your customer or business team it is your job to fix it.
If there is a lot of questions arising during estimation that cannot be answered in a reasonable amount of time, there’s no way around it – assumptions will need to be made. The key is to make note of these assumptions and document them as risks in your final estimation. This will be key in helping the business prioritize the project. If there is a lot of high risk items the decision to start straight away may be best. On the other hand maybe the risks just outweigh what we hope to gain, and the project is scrapped. The point is to provide enough information for the business to make an educated decision. It is interesting to note that a lot of these technical assumptions are due to technical debt. Minimizing technical debt makes high level estimation much simpler, but I will leave that topic for another post.
When we first started providing high level estimates I had little knowledge as to where to even start. Being a former developer I too suffered from many of the above points. The bare minimum is to get the team to break down the tech project into logical, more manageable pieces. Briefly discuss these logical components to ensure that everyone has a shared understanding. It’s at this point that assumptions are likely going to be identified.
Once you’re ready to estimate that specific items try what I’ve been calling the Goldilocks technique. Throw out a number like “2 weeks” and ask if it is too much time, not enough time, or just right. Modify your number and repeat as needed. It is a good idea to sometimes provide more than one estimate based on the presumption that certain risks may come to fruition.
If your team has the understanding that the estimate they are providing is an educated/best guess that is going to provide the business with the knowledge needed to steer the company in the correct direction, the more willing they will be to engage the process. These are decisions that need to be made, and I’m sure everyone is more comfortable if it is the development team providing these estimates as opposed to the executive team who doesn’t have the expertise required. In a perfect world we would know exactly how long every project would take, but this isn’t a perfect world so all we can do it work with what we have. At the end of the day we are all working towards the same goal, and as long as the development team and the business team understand the purpose as well as the limitations of the estimates, the more likely those goals will be achieved.
Challenges Facing the Fusion of Agile Teams
Recently there was some major shuffling of the development teams at Point2 which resulted in me leading a team of seven developers. Of those seven only two were on my previous team. Even though all of the teams were developing software using Scrum, each of them had specific processes and practices. One of my challenges as the Team Lead was finding a way to effectively bring all of these people together who were used to their team running a certain way.
The easiest thing I could have done was to just decide how things were going to run and inform the team. This would have also been the worst thing I could have done. Teams are supposed to self-organize and they are going to have an easier time doing this if they are working in a way that they feel comfortable.
So what did we do to expedite the fusion of the team members into a new group?
- Get the team into a room to hammer out ideas regarding how iterations were going to run such as Sprint length, required meetings, etc.
- Encourage all team members to talk about why certain things worked well on their previous team. We want to make sure that the best processes and practices are being discussed. It’s easy for people to be less opinionated in a new group.
- Manage the expectations of the team and the customer/business. The team and business people were likely used to work getting done at a certain pace. Getting a new team to mesh is difficult and takes time. Make sure everybody understands this to prevent the team from getting frustrated, and the business from wondering why things have slowed down.
- Even though we do hold Retrospectives and Root Cause Analyses at the end of every Sprint, it is in the early stages of the new team that these are critical. These are the times where problems with the processes and practices will most likely be raised and discussed.
- As a Team Lead or ScrumMaster you have probably seen what works well and what does not. Find that balance in guiding your team in the decision making process without pushing them down a path for purely personal reasons. There may be times that they want to try something that you have seen fail previously. Under certain circumstances it may be best to let them try it. If it works, great! But if it does not it can also act as a good learning experience.
The new team has been together for about three weeks and has been running quite well. Our Sprints have been a little bit unpredictable and sporatic as we are working on a mash-up of stories from previous teams. Despite that our velocity was still most impressive for a new team.
I think the majority of the success has to do with the Agile maturity amongst our developers, but I also think that the team working in a way that they have fashioned is also playing a factor. It may seem like an obvious statement to say your team should decide how things are run, but it is also easy to get stuck in one’s ways, and just do what you’re used to.
Point2 Talks Software Craftsmanship at Career Fair
This past Wednesday the Computer Science Students’ Society held their annual Career Fair at the University of Saskatchewan. Point2 has been involved in these recently and this year was no different. We had a booth set up on the main floor giving us a chance to speak with students who would soon be entering the industry. It was also a great way to showcase all of the progressive things we do to attract all of the brightest minds.
We were also given a twenty-five minute slot to present to the students, so my fellow Team Lead Mark Hollman and I used this as an opportunity to discuss how Point2 is adopting the idea of Software Craftsmanship. This is a trend that has started to gain momentum in the industry, treating software development as a modern day craft. It was great to bring this movement to the students’ attention (nearly no one had heard of it) so that they could start to think of their upcoming career as a craft.
Mark and I felt as though we did a good job in demonstrating how working at Point2 is not only a job, but also a guaranteed path to learn, to teach, and to nurture the passion that so many software developers have for their craft. It is these differences that make a job as a Point2 developer a career.
Point2 Speaks at CIPS Luncheon
Last Wednesday Point2 had the opportunity to speak at a CIPS (Canadian Information Processing Society) Saskatchewan luncheon hosted at the Potash Corporation of Saskatchewan tower in Saskatoon. The topic that Joel Loewen, Melanie Cey, and I presented at their request was IT Recruitment Issues Unique to the Saskatoon Area.
Join Melanie, Joel and Hemant as they discuss their particular challenges and success factors. Hear how their shop differs from a typical IT support organization and what they are looking for when they hire IT professionals at Point2, and other HR challenges.
Once we arrived at PCS we had a chance to mingle with the thirty or so guests that were in attendance. It didn’t take long to realize we would be speaking to quite an eclectic bunch ranging from students to development managers to HR recruiters. After lunch was served it was time to get down to business.
Joel started it off with introductions and then handed it over to Melanie who gave a brief summary of Point2, discussing the evolution of the company over the last fourteen years. She gave an overview of the two major product lines in regards to heavy equipment and real estate, and the steady pace at which the company continues to grow.
I was next on the agenda and spoke about the unique development shop we have put together in Saskatoon. I briefly discussed how we used to develop software and why it had to change if we wanted to continue to be a progressive company. I got into the meat of my talk when I illustrated our move to Agile development practices including Scrum and XP, how we were starting to look at software development as a craft, our open work environment, and the culture of learning we have created by embracing professional development.
Joel followed up with a detailed look into the IT department. He spoke about the challenges we face as our business and data needs grow, and the complexities that we have to overcome by hosting our systems on-site. His explanation of our move to virtualization was eloquent and illustrated the level of expertise in our systems department.
The idea was to lay down the the unique technology environment that has emerged at Point2 before getting into the challenges it creates regarding hiring. This opened up about a forty-five minute question period around our recruitment process, our technology stack, and the Agile development practices that we have adopted.
All-in-all the presentation was well received and it was great to have a chance to highlight all of the great things that are happening at Point2. On behalf of Joel, Melanie and myself I would like to thank CIPS for inviting us to present at their luncheon. It was an honour to be involved in important discussions regarding the challenges that Saskatchewan based technology companies are facing.
Is Tardiness Contagious?
Meetings are a regular occurrence in all office environments, and it is no different for an agile software development team. With the majority of of our teams following Scrum, the Daily Scrum, estimation, and retrospectives are just some of those many meetings. Even though my particular team has become quite efficient at running these meetings, there remains one problem that is common amongst almost all of them – people are always showing up late to them. This very problem was the focus of our last root cause analysis meeting (and yes, people showed up late to that one as well 
) as we hoped to identify reasons for meeting tardiness.
After drilling down into the problem, my team identified four categories that played a role in tardiness amongst members of our software development team.
Focus
- Since we do 100% pair programming on our development team, a developer feels bad if they need to leave for a meeting that their pair is not in.
- A pair is usually in some sort of flow while working on a problem and they often find it difficult to leave abruptly.
Complacency
- It is generally okay for meetings to run long, so people start to think it is alright to show up late.
- Meeting invitation notes (agendas, goals, etc.) are not read until a few minutes prior to the meeting start time, resulting in people being late.
- It has just become the norm. We have started accepting people being late as business as usual.
Scheduling
- Coffee and bathroom detours are made on the route from desk to meeting location.
- Meetings scheduled on the hour/half-hour are not disruptive enough to garner full attention.
Software
- Since developers are pairing most of the time, they are rarely at their own desk to get the meeting reminders.
- The snooze function and meeting reminders in Outlook and Entourage are not reliable.
It was no secret that this was a problem faced by all teams in our department (I can’t speak for other departments) so we came up with some action items that we could start to implement (on our particular team, at least).
- Simply round people up prior to the meeting. This may only work if you are all located in the same area.
- The organizer of the meeting should be the first person to show up, and welcome the attendees as they arrive. Many times people show up to a meeting room and no one is there, so they too wander off.
- Identify the meetings for the day at the Daily Scrum.
- Just start the meeting on time, regardless of whether everyone is there or not. People who show up mid-meeting will get the point.
- A more extreme method which will not work all of the time is to simply cancel the meeting if everyone is not there on time.
It’s been a week since we’ve started tackling this problem and I can say that there has already been improvements made. Even though there is still a ways to go, we are confident that tardiness will soon become a thing of the past. The idea that we have become complacent to people showing up late just means that more and more people will follow this trend. If we can just turn that attitude around I think we can successfully make punctuality just as contagious as tardiness.
Let’s Learn from Each Other: BarCamp Saskatoon 2009
Last weekend members of Saskatoon’s technical industry congregated at Louis’ Pub on the University of Saskatchewan campus for the annual BarCamp, a technical conference “for the rest of us.” For those of you who are not familiar with BarCamp, here is a little history as explained on the website.
The idea of BarCamp came from Foo Camp where a bunch of the best techie minds in the world got together to talk about new technologies, and to create opportunities for cross-fertilization between people and technologies.
Since only the top minds from O’Reilly, Google, Yahoo, Intel, Apple, etc. were invited to attend, two people in California decided to make a Camp for the rest of us. Now, there are BarCamps somewhere in the world almost every day.
This was the first year that I attended BarCamp so I wasn’t quite sure what to expect. I did understand that it had a laid back atmosphere which is quite apparent since it is held in a bar, but I also knew that the caliber of the talks would be high. The idea behind BarCamp is that everyone who attends has to participate in some way ranging anywhere from helping set up to leading a presentation.
As to be expected there was a high number of Point2ers in attendance, and impressively four of the nine presenters were from the office. Dave Kellow gave a spirited talk on Agile Modeling explaining why it is important, and discussed ideal ways of approaching the subject. Nate Heagy gave a brief, but extremely informative and entertaining presentation on Why You Should Get Good at Javascript. He used this as an opportunity to showcase an iPhone app he wrote using this technology as leverage. Chris Powell teamed up with his buddy Mark Poppen to give an information session on Starting a Web-based Business. Sean Reilly then wowed the crowd with his extensive knowledge of effective Functional Testing techniques, and why they are so important.
The time between all of the great presentations provided an opportunity for the attendees to mingle and find out what each other was up to. Being in a relatively small market, Saskatoon has a limited number of events like this so it is rare for members of the industry to get together and just hang out. Even though many different companies were being represented the atmosphere was of collaboration, not competition. Everyone was there to learn from each other in hopes of bettering themselves professionally. It’s events like these that will have a positive effect on Saskatoon’s technical community moving forward. On behalf of Point2 I would like to thank everyone who made this event possible.
So you may be asking how I contributed at this year’s BarCamp. Well I didn’t help set up or lead any presentations, but I did shoot a lot of photographs to document the event. You can view the shots from the day here. The local media was also there to cover the conference and you can read the resulting article here.
Was Our Velocity Seriously Zero?
Two Sprints ago something happened for the first time since I have been a Team Lead – my team’s velocity was a big fat zero. As a team we are fairly experienced in Agile and Scrum and quite self-organizing, yet somehow our Scrum board was portraying us as a rookie crew. The first question that may come to your mind is, “did you guy’s have to deal with a lot of production bugs or injected stories?” Sadly the answer would be, no. The team obviously wanted to get to the bottom of this anomalous Sprint so performing a root cause analysis seemed like the right thing to do.
After working through a root cause analysis exercise as a team (this is actually something we do on a weekly basis) we had a pretty good idea of what had contributed to us delivering a big fat goose egg. There were no real surprises revealed, but it did help to get some stuff written down and in front of our faces. On a positive note, the team did agree that even though we didn’t burn up any stories, a lot of work actually did get done. So what went wrong?
- The was a lot of technical unknowns in the new project we were working on resulting in stories with fuzzy boundaries.
- The team was unsure when they were done a story, and as a result they dragged on longer than they should have.
- Our stories were obviously poorly broken down.
- We were not representing the work that was actually getting done properly on our Scrum board.
- The knowledge gained from earlier spikes may not have been leveraged to their full potential.
- We had gotten a little too comfortable in our Sprint planning process. Our previous projects (in the recent past) were usually well defined and understood. Because of this we found ourselves spending less time planning because we could get away with a just in time mentality. This didn’t work for our current project.
Naturally we want our root cause analysis exercises to result in some sort of action plan. With an understanding of what led to our questionable Sprint, the team was able to put some corrective measures into place for the start of the next Sprint.
- For each story/task on the Scrum board, represent hurdles and stalls visually. Even though we talk about them in daily stand-ups, seeing them on the board can help show severity if it goes on for a long period of time.
- During our kick-off meeting break down each story into small, bite-sized tasks and use these on the Scrum board. They should be small enough that we have no cards on the board that have a complexity value over 1 – the smallest size possible on our scale.
- Do not end the kick-off meeting until all task cards are completed, prioritized based on importance and dependencies, and a commitment has been agreed upon.
- If we find ourselves doing something that is not represented on the Scrum board,
- ask yourself if you should even be doing it.
- if you should be doing it, write up a new card and put it on the board to ensure that everything we do is tracked.
- Continue with one week Sprints.
So how did the team fare after putting their plan into action? They met their commitment. The kick-off meeting resulted in a Sprint plan that was straight-forward and well defined. It provided a clear-cut set of tasks that the team could easily base their commitment on. During the Sprint they were more mindful of the work at hand and made decisions as to whether it belonged in the iteration or not. As a whole we re-focused on areas that we had gotten too comfortable with and neglected.
It was very satisfying to see the team face this problem head-on. They calmly analyzed it, devised an action plan, and executed it. They could have easily panicked, but they didn’t. They proved that they were a mature team that could recognize a problem, and use their agility to correct it.
Shuhari and the Evolution of the Team
The concept of Shuhari was mentioned on more than one occasion while I was at Agile 2009 in Chicago this past summer. Alistair Cockburn was the first to mention it in his keynote speech I Come to Bury Agile, Not to Praise It. It then surfaced again when Declan Whelan spoke about Learning is the Key to Agile Success: Building a Learning Culture on Your Agile Team. Shuhari originated in Japan as a martial arts concept describing the stages of learning to mastery. The word is actually three words combined.
Shu – protect or obey. It is based on traditional wisdom where the student learns all they can from their master, and accepts any instruction and criticism they are offered. The master acts as a protector, steering the student and watching out for their best interests.
Ha – detach or digress. Up until this point the student did everything based on fundamental teachings. At this point the student will start to break with tradition and apply more imaginative techniques, building on what they have learned. They will also start to question and start to evolve based on their own personal experience.
Ri – leave or separate. At this point the learner transcends to a point where there are no longer specific techniques that are being followed since everything now come naturally. The student has learned everything they can from their master and leaves. The student bases their learning almost completely through self-discovery with no actual instruction. Ideally the student should have surpassed the master, allowing for the art to progress.
I found this concept to be very intriguing and it got me thinking about how it applies closer to home. The development team at Point2 is always in a state of learning. In many instances the student and the teacher roles are obvious. A new college graduate will likely be paired with a veteran developer in a mentoring role, while more experienced developers will pair with each other, hopefully learning from one another. I really believe that the last point in the Ri description is key. In order for the art to evolve and progress, the student must surpass their teacher.
A dilemma arises when everyone reaches that Ri stage and no one is able to get back into the Shu mindset. If everyone believes there is nothing new to learn, an obvious problem is created – your team will likely fail because they will lose their ability to compete. This is where having a culture of learning is paramount. People have to think of ShuHaRi as a circular idea that has no beginning and no end. If an entire team is dedicated making their colleagues the best that they can be, and are willing to learn from each other, the possibility of stagnating as a team fades away.
How is Point2 attempting to keep Shuhari a cyclical pattern? We mentor our new recruits, putting trust in our veteran developers to lead them down the correct paths. We pair program nearly 100% of the time, ensuring that developers are always teaching each other new techniques and skills. We dedicate Friday afternoons to personal professional development. People can choose to present or lead a workshop for a group, get together to develop a small application, or just spend some me time reading a book or watching a webcast. The point being is that our development team understands the value in learning and can see the relationship between the development of their careers and the success of the business. Shuhari may not be a well known concept in the halls of Point2, but that doesn’t mean it’s not alive and well.
With Etudes, Practice Makes Perfect
Professional development is very important at Point2, and we are always looking for ways to foster that culture of learning. Last week I introduced my team to etudes, an idea that was very briefly touched upon by Declan Whelan in his Learning is the Key to Agile Success: Building a Learning Culture on Your Agile Team talk at Agile 2009. Most people understand an etude to be an, “instrumental musical composition, most commonly of considerable difficulty, usually designed to provide practice material for perfecting a particular technical skill.” Taking that definition, the concept of an etude in the software development world doesn’t seem too far-fetched.
Many people are starting to view software development as a craft that can be improved upon with practice. This is evident in the emergence of Code Katas, self-contained coding exercises designed for developers to hone their skills. An etude is similar to a Code Kata, but is usually smaller and can be completed in a reasonably short period of time. I wanted the etudes on my team to be very small and designed in a way that would allow the developers to continue working on their current tasks.
After explaining the concept to the team at a recent Retrospective we all agreed to come up with at least one etude by the end of the next Sprint. To our disappointment there was virtually no information or ideas on the net so we had to rely solely on our imagination. I even contacted Declan for ideas, but was told that he had similar problems finding helpful resources on the subject. Once our Sprint wrapped up the following week the team had managed to come up with some ideas.
- No mouse for 30 minutes
- Pairing ping-pong for an hour
- No looking at the keyboard for 30 minutes
- Print off shortcut list for IDE and don’t use menus for 30 minutes
- Paraphrase every instruction/comment that your pair makes for 30 minutes
On Wednesday at about 2pm I stood up and announced to the team that they could not use their mouse for thirty minutes. After the gasps subsided the mice were set aside, and the the pair continued with their work. As one member of the pair struggled with certain commands we often found that the other member knew the shortcut and passed on the knowledge. Some developers were smart enough to print out the shortcut list a few days prior.
So what was the point of this exercise? While working in an IDE such as IntelliJ, shortcuts can be invaluable in how fast one can work. Learning to use the keystrokes as opposed to moving back and forth between the mouse and keyboard is a goal for many developers, and removing the mouse from the equation forces them to learn them. And as we also found out it can help a pair of developer share their knowledge. Just like in music, you can’t do a musical scale once and be an expert. The idea is that the more often you practice the scale, the better you will get. This particular etude we tried will help the developers learn the keyboard shortcuts as long as we keep practicing them.
This was the only etude we tried in the Sprint, but the plan is to continue throwing them out there when it seems appropriate. Let’s just say that I wouldn’t have announced the etude if we were in the middle of fixing a high priority production bug. But just think, by continuing to do these performance enhancing exercises, we should be able to get those production bug fixes (and new features) out the door that much quicker.
If you have any etude ideas we would love the hear from you.
Share on Facebook
Recent Discussions