The Role of the Architect in Scrum

December 29, 2009 1 Comment

This question comes up over an over, so I thought I’d address it quickly.

Remember that in an ideal Scrum team, the team is completely self organizing.  There are no titles to worry about.  The team will discover the strengths and weaknesses of each member, and continuously evolve, i.e. inspect and adapt, to discover new ways of delivering high quality value to the business.

But, guess what.  In the real world, we have titles to deal with.  Now, I don’t think that’s such a bad thing.

As we all know, the title “Architect” in the context of software means very different things given the organization.  I’ve seen it range from really good coder to more of a project manager-y type of position.  I think this lack of clear role in the industry overall has lead the folks in this title to, at times, become “chickens” that like to cluck and flap their wings to distract the team.

So, what should the architect do?  Well, let’s remember that in Scrum, team are self organizing.  They collectively come up with the technical solutions.  They also come up with development standards.  If the team is generally not high performing, or are missing some necessary skills, then the architect should be a mentor and a coach for that team until they can fly on their own.

What if the teams are high performing?  If there is an organizational need due to a highly complex business need, i.e. insurance, taxes, financial transactions, etc., then the architect should focus on the high level roadmap to ensure that the backbone of the technology is strong.  This is especially true in a SOA environment.

Advertisement

Filed under Roles, Scrum Tagged with , , ,

Creating the Sprint Backlog in New Scrum Teams

December 28, 2009 1 Comment

If you’re new to Scrum, here is something you need to know about teams first trying it out…ready??

…drumroll…

The team doesn’t know what they need to do

There, I said it. Whew, glad I got that off my chest.

In Scrum, we ask team members to break product backlog items (typically stories), into tasks that take 16 hours or less to complete. You will find that, most of the time, the team will have incredible difficulty in doing this, and they will likely come up with tasks such as “analyze, code, test”. Bleh. Those are B.S. tasks that really don’t mean anything. It’s hard to define “DONE” for those types of tasks. You may have to accept those tasks in the beginning, but it is your responsibility as a Scrum Master to coach the team into creatively thinking through task definition.

Here are some reasons I think teams may have a hard time defining tasks.  It is best to look at all of these as impediments, and your job as a Scrum Master is to remove them.

  • Lack of Empowerment
    Teams under the tyranny of “traditional” development are rarely empowered. They are used to being told what to do. While creating solutions, team members will actually do what needs to be done and then move on to the next thing. The problem is that they’ve never had to articulate the steps they take to complete what they need to complete.  And, to top it off, managers rarely understand what it “really” takes to deliver a solution. 

    This will not be a quick fix.  You will have to work with leadership and come up with a strategic plan on how to empower people.  In the meantime, even though you tell the team “your empowered’, if the rest of the organization does not support it, there will be constant struggle.  However, as a leader, it is your job to work both sides of the fence, i.e the team and the organization.

  • Fear
    In an extreme command-and-control environment, people lose all common sense. They are not confident making any decisions, let alone actually thinking for themselves. 

    Here, the team will need lots of praise and protection.  If they know that you have their back, they will, over time, come out of their shells.

  • Lack of Knowledge or Skills 

    If the team is new to that domain, or the team just does not have the skills, i.e. a Cobol programmer “trying out” Java development, there is no way they can effectively decompose stories into tasks.

    This is one of the toughest situations to deal with.  If the team is just the wrong team, the only thing that can be done is to escalate this impediment to leadership.  This one is particularly hard because I guarantee that there will be others who think some of those on the team DO have the knowledge and skills, likely because those folks are “well liked” or popular.  Just remember to be honest always, and over time, change will happen.

  • “The Dominator” 

    Sometimes there is one person on the team who holds the key. They know the domain, they know the technology. No one else does. THEY are the ones who define the tasks. If the tasks aren’t good enough, who cares, as long as “The Dominator” is okay with them. This is a tricky one. It is your responsibility to either a) get them off the team or b) clearly set the expectations and time-box the needed change in behavior.

If you are a Scrum Master or coach on this team and you don’t have “tribal” knowledge, it will be a true test of your patience.

But, hope is not lost! A while ago, I was in this situation. I was in a sprint planning session, and I saw the familiar signs emerging…”Ummm…yeah…we need to analyze”. “Oh, I suppose we need to code too”. UGH. I was helpless. Luckily, there was a strong technical lead attending that understood the domain and technology. He patiently walked the team through the decomposition of the stories into “real” tasks. It was a real humbling experience for me. I thought I could get ANY team to decompose stories into meaningful tasks. Boy, was I wrong.

So, if you’re in this situation, determine the “root cause” of why the team can’t decompose stories into meaningful tasks. If it’s an impediment, handle the impediment. If it’s because you are lacking the knowledge necessary to coach the team, find someone there who can.

Filed under Agile, Process, Scrum Tagged with , , , ,

Evangelizing Scrum, or Anything, is Hard

December 25, 2009 Leave a comment

Ever since I discovered lean/agile, I’ve been very perplexed about something. Why do so many people feel passionate, and sometimes offended, when I introduce it? Seriously, offended. Like I just called their baby ugly. I was taken-aback at first, now I’m used to it. I think I’ve learned to dodge most of the stones that people throw over the years.

Lean/agile begins with principles, with practices emerging from these principles (see previous blog post about agile principles).

I think a lot of blame (yes, I’m pointing fingers) comes from people who don’t understand agile, then implement it…POORLY. I’ve heard so many horror stories about failed Scrum or Extreme Programming implementations. I’ve taught quite a few classes about agile/lean methods, and in every course, I ask the students if they’ve been involved in some kind of agile implementation. For everyone that said they had been involved, they said that it sucked…100% of the time. As they expanded on the sucky-ness, I just cringed. The leaders of the implementation just didn’t get it. They didn’t understand that it’s about principles, not about index cards and stand-ups.

Now, let me relate this religion. I’ve been a Christian for close to 20 years. Every time I get into any kind of conversation (which I rarely start), people immediately become offended. Why? Because like the poorly executed agile implementations, there are many poorly executed “Christian” implementations.

As humans, it is so much easier to just follow rules than to rely on our own judgement. That’s why empowerment is rejected so many times at the lowest level. If someone is empowered, then they are also accountable. Who wants THAT??

Christianity is not about rules. If anyone tells you that, then they need to go to Christianity 101 class. Christianity is about a relationship, and principles. If you follow the principles, the “practices” will follow.

Let’s look at the greatest principles (commandments) given by Jesus “Love God with all your heart, soul, and mind”, then “Love your neighbor as yourself”.

What’s interesting, is that if you take these to heart, then the 10 commandments (don’t lie, murder, steal, etc.) will follow…right? The greatest principles will naturally manifest themselves in the 10 commandments.

If a Christian truly loved their neighbors as themselves, I think you would see a lot more philanthropy and a welcoming attitude towards others.

Here’s the intro into the song “What if I Stumble” by DC Talk that summarizes my point beautifully:

The greatest single cause of atheism in the world today is Christians who acknowledge Jesus with their lips then walk out the door and deny him by their lifestyle. That is what an unbelieving world simply finds unbelievable.

Since in general, the “implementation” of Christianity has ignored the primary principles, the understanding from the non-Christian population is that Christians are ignorant, stupid, hypocritical, judgmental, and hateful. Are Christians doing anything to change this image? Not really.

So, when “evangelizing” given this climate, people become hostile and have a desire to throw (verbal) stones.

Now, back to agile/lean. Generally speaking, many folks believe agile is nothing but cowboy coding, no documentation, speed not quality, and screw “the business”. When “evangelizing” given this climate, people become hostile and have a desire to throw (verbal) stones.

Evangelizing anything that is based on principles stirs emotion and is fraught with mis-understandings. Typically our first instinct is to run from the conflict that arises and just become complacent and accepting of dysfunction and misunderstanding. We need to be brave, and stand by our principles. In doing so, we need to continue to come up with ways to communicate the truth.

Filed under Scrum Tagged with , ,

The Cross Functional Team vs. the Functional Community

November 9, 2009 1 Comment

An agile team consists of everyone it takes to deliver value to the customer.  The typical team consists of analysts, developers,  and testers. Of course the team is not limited to these roles.  The team could also include technical documenters, DBAs, or whoever else has a hand in creating value.

In traditional organizations, “team” is defined as a functional group.  The development “team”, the “testing” team, the “analyst” team, etc.  This makes sense in a traditional, waterfall-ish environment.

In an agile, cross-functional environment, it is not helpful to define “teams” around functions.  Okay, “maybe” its okay in a production support capacity, but that’s still pushing it as there will still need to be cross-functional work with production support.

Teams have a common, unified goal. Functional “teams” do not.  For example, a functional “team” that consists of a dozen Java programmers, with each programmer on a different project, can hardly be called a “team”.  They have no common goal, other than to adhere to the (hopefully) high development standards that have been put in place.

I propose that instead of calling these functional groups “teams”, we call them communities.  Here’s a simple definition of community that I found on dictionary.com: “A group of people having common interests“.  The Java “community” will work together to make sure that they have common standards of excellence, share knowledge and experiences, and provide each other guidance as needed.  However, these people will have different goals, depending on the project on which they have been assigned.

Filed under Agile, Roles, Teams Tagged with , , ,

Scrum Documentation

January 2, 2009 Leave a comment

If you are on an agile team, and you are telling your team that you don’t need to document because your “agile”, stop it. Stop it right now!! You’re making my life difficult!

There is a strong stereotype out there, and its that with agile, you don’t document. Arggghhh!!! I’m sure some of you have experienced it.

Here is what I tell people when they ask about the documentation requirements on an agile project…”If the team needs it, then they will create it”. Now, I’m not talking about documents that are delivered to the customer, like help documents. I’m talking about documents such as architecture diagrams, “requirements” documents (eww), process flow diagrams, diagrams, and more diagrams.

IF these kinds of documents will make the team more productive, and produce higher quality software then document! Now, the next thing I tell people is to be LOW TECH. I mean, c’mon, do you really have to transfer that diagram on the whiteboard to visio? I’ve seen people take 2 weeks to do that, as the rest of the team is “waiting”, i.e WASTE. Why not take a picture? It’s going to change anyway, right? And, we “want” it to change, if we ever want to improve.

Remember, the end customer does not value these kinds of documents. So, DON’T SPEND A LOT OF TIME ON THEM. If your company “requires” them, then take the lowest road approach possible. Ask questions. Challenge the “process”. Processes were meant to change and improve, you should not be a victim to them.

Okay, to review….

  • Documentation can be good, if it makes the team more productive and the customer happier because of higher quality. But, BE CAREFUL
  • Low tech = Good
  • The customer DOESN’T CARE about those documents, so just take it easy there partner. Only do the bare minimum that you NEED.

Filed under Scrum Tagged with , ,

Sprint Planning When Everyone’s New

March 2, 2008 Leave a comment

We were working on a legacy product written in PowerBuilder. There was one engineer that had been around for a while, about 6 years. Another had been around for a little less than a year, and the rest were brand new. The entire QA team was new. They weren’t only new to that project, they were new to QA. There was also a team of business analysts. Most of them had been around for several years, but there were only 2, and this was a big project.

As to be expected on teams such as this, the process was very waterfall-ish and chaotic. The team waited for the BAs to create “the specs”, and QA waited for engineering to do the coding. Lots of waiting.

It was my job to implement Scrum at this company. We finally had a product backlog that was prioritized, but that was about it. Even though that was such a small accomplishment, it made a very positive impact on the team. Before this, the team never new what to work on next, and usually worked on things that had to be abandoned later.

So, we have a product backlog. We still hadn’t conducted a release planning or a sprint planning session. I decided to start with a sprint planning session.

Sprint Planning Session 0 = Miserable Failure

Our first sprint planning session was a disaster. First of all, the QA team did not show up. I almost just canceled right there, but I thought I’d continue this disaster.

We projected the product backlog (which was in excel) and started going down this list. The goal was to define “Done” for each item, and also to decompose it into smaller tasks, with each task less than 16 hours.

We got stuck on the first item. Everyone said “I’ll have to go back and look at the spec” for every item we brought up. And if there wasn’t a spec, it was just impossible. Everyone just stared at each other like deer in the headlights.

I also heard the engineers say things like “we’ll have to go into the code, it will take a couple of days to break this down”. Or “there is no way we can break down this 180 hour task” (yes, they had estimated the product backlog items in hours).

We canceled the meeting about 15 minutes into it. While I was very disappointed that it failed, I was excited to have a new challenge. In addition, it was great that I learned something about the inner-workings of the team. How do you conduct a sprint planning session when no one knows how to implement the features in the backlog?

Sprint Planning Session 1 = Moderate Success!

I was sure that the team just needed to do homework. But, after talking with the old timer, I realized that homework was not enough!

The code base was extremely unstructured. It had grown over the last 12 years into something really ugly and barely maintainable. Not even the engineer with the most experience would have been able to come up with sprint tasks that were 16 hours or less. I got some great advice from someone on the yahoo scrum group, about maybe using spiking to help decompose the backlog items. While I love the idea, there was no way we had time to do this on every item.

So, here’s what we did. We encouraged team to do some research on the upcoming features.

Then, in the sprint planning session, the team self-organized into smaller teams, and dug in deep on the features. We printed specs out for them, and of course had the BAs there (which were ultimately playing the role of product owner).

The engineers had their laptops so they could look into the code if necessary, I suppose doing “mini-spikes”.

This time QA showed up, but they were there in bodies and not in spirits. But, that’s a subject for another post.

We still did NOT come up with a sprint backlog. I was a little disappointed in that. However, the team came out feeling like a true team, and with a clearer understanding of the sprint ahead of them. We also had a clear commitment (which the business broke, again, for another post).

It was a definite step in the right direction. While we weren’t able to derive the sprint backlog, the team bonded during the exercise. The team also understood what they needed to deliver (they just weren’t sure how at that point). In addition, we realized where our problems truly existed.

Filed under Scrum, Teams

The Role of the Functional Manager in Scrum

December 30, 2007 Leave a comment

One of the surprises that I have encountered is the resistance to implementing Scrum from the functional managers. Just to clarify, functional managers refer to the QA manager, software development manager, BA manager, etc.

One of the things that Scrum does is provide a very simple framework with very few well defined roles. The only roles that are clearly defined are Scrum Master, Product Owner, and Team. Click here to find out more about these roles.

Nowhere does it define a “QA manager”, or “Software Development Manager”. I think I understand why. In traditional, “waterfall-ish” environments, everything is separated by function. There are functional silos where the manager will tell their team what to do. The QA manager will manage the work for the QA team, the software manager will manage the work for the software team, etc. Scrum emphasized cross-functional and self-organizing teams. This is a complete contradiction to how the functional manager has been trained to work.

When I was confronted by one of the functional managers, I was surprised at first. He felt that there was no place for his position, and that his job was in jeopardy. I assured him that this wasn’t the case, that his position was important and that it just needs to change. Then, I thought about this more. What IS the role of the functional manager? They don’t manage work. They (usually) don’t DO the work. They aren’t really chickens or pigs.

I searched for some time for some clear direction. After quite a bit of searching, I found out that this was one of those things where the answer was “it depends”. There was no clear-cut answer.

Depending on the needs of the team, there may be no place for functional managers. If the team is small and self-managing, the scrum roles are being filled competently and impediments are being removed without help from the functional manager, then I don’t believe there is a need for functional managers. However, there aren’t many organizations that will achieve this state of bliss.

The functional manager can serve very important roles within organizations that have implemented Scrum. Below are some ways the functional manager can add value.

  • Ensure each team member’s skills are kept up to date. This is a big one, and could consume a large portion of the functional manager’s time.
  • Help remove impediments. I have experienced situations in which there were just too many impediments for one Scrum Master.
  • Play the Scrum Master role on projects as necessary.
  • Help with resource allocation. Notice that I said “help with”, not “do”. This is more important with teams that have not attained the “self-managing” phase yet. Many times the functional group has to serve on many different projects. The functional manager can work with the team, Scrum Master and product owner on project assignments.
  • Handle personnel issues, paperwork, etc.
  • Participate in the hiring process. In a truly self-managing organization, the team would do the hiring. Until self-managing is fully realized, the functional manager can facilitate this.

Implementing Scrum does not automatically eliminate the functional manager role. However, it absolutely changes it. The functional manager will have to be willing to “release” some (most?) of their authority to the team. They will have to become a servant-leader.

Filed under Roles, Scrum

Newer posts →