Only Passionate People Win : Agile Development

Accountability in Scrum

youngjoo — Tue, 23 May 2006 01:49:00 GMT

Doug Seven wonders accountability issue with Scrum. And yag wants to discuss this further. If you read follow up comment Doug posted for his entry, you can easily discover that the team is still in learning phase.

Folks. Scrum is not a magic bullet. There is no such thing as a magic bullet.

Only three sprints. Do not expect the productivity to go up dramatically after three sprints. It doesn't matter how many training sessions team had with who. It doesn't matter how many books team members read. And it really doesn't matter whether you have an experienced Scrum Master in the team. It takes time.

Scrum Master should be careful about painting a rosy picture when working with a team that does not have any Scrum experience. Scrum Master is responsible for setting the correct expectation with the team and working with the team to guide them through the initial dark-period. Team productivity will dip. It will probably be worse than whatever previous process the team was using. Team moral will dip. People will start questioning whether Scrum is the right thing or not. Management will put increased pressure to the team as the team struggles to meet their commitment sprint after sprint.

Every aspect of Scrum is very different. User stories instead of full spec, size-based estimates, daily meetings, acceptance tests, velocity tracking, new engineering practices such as TDD, Continuous Integration, pair programming. It requires a mind shift. And expecting the team to produce more stuff after just a few sprints is just wrong expectation. It will NOT happen.

So, going back to the accountability issue. I think management and Scrum Master should be held accountable in Doug's team's situation since they set the wrong expectation and have not given ample opportunities to the team to learn this very different way of developing.

Technorati Tags: agile scrum software+engineering

Yag moves on and why I believe our paths will cross again

youngjoo — Fri, 05 May 2006 22:16:00 GMT

Yag moves on. He used to be the Group Manager of Visual Studio Data team before the team got merged into Visual Basic product unit and became a part of Visual Studio Professional Data team. Although I only spent a couple of months in Visual Studio Data team and only had 1 face-to-face meeting with him, I learned a lot from him. You see, it really doesn't require multiple encounters to learn great stuff from a great person. You know it when you meet that kind of person and you naturally absorb great stuff from that person like a dry sponge. That's what happened when I met yag.

Well, I actually had two face-to-face "official" meetings with him. One was during my interview and one was after I joined VS Data team. I think I only spent abouut 30 min with him during my interview. But that 30 min definitely helped me decide to eventually accept the offer. I met great people during my interview process and yag just sealed it at the end. We mostly talked about my passion around Agile Development. The second "official" meeting was the 1-on-1 he scheduled with me. During that meeting, he showed his passion around community. We also shared some frustration about how community stuff was done. Oh, don't get me wrong. That frustration was from being too passionate about something. I guess "frustration" is the wrong word for that...

Now, why do I think our paths will cross again? It's because we share same passion, creating great software that customer really needs by being pragmatic (Agile + Community). If you ask me, I rather listen to the customer and provide solution that just works as soon as possible rather than worrying about hundreds of other political, process and architectural things (a.k.a. impediments). If you ask me, I rather sit with the customer during the project cycle than in my own office guessing what customer needs. If you ask me, I get more excited when I get a small "thank you" note from the customer I helped than when I receive a "job well done" message from my manager. And I believe that's where yag's passion lies also.

Best wishes to yag in his new and exciting role.

Tags: microsoft, agile development, community

How can Visual Studio, Office or Windows teams adopt Agile?

youngjoo — Fri, 28 Apr 2006 21:43:00 GMT

Scoble ponders about how Agile methodologies such as Scrum can be applied to Visual Studio, Office or Windows teams in his Another test of "is Microsoft listening" post. Scrum is everywhere now. Even Scoble talks about it.

I do firmly believe that Agile methodologies can be adopted by ANY development team as long as people understand what benefits Agile brings and plan carefully. Scoble mentions the deployment issue as one of the reasons why Office or Windows teams won't benefit from Scrum. Although he has a point, that isn't true. It's a very common misunderstanding people have about Agile methodologies. Sure, "ship every two weeks" sounds very attractive. And it's one of the reasons why people are so excited about Agile methodologies. However, it's not about ship every x weeks. It's about building shippable software every x weeks. People often do not realize that Agile teams have iteration planning and separate release planning. Iteration planning is about committing to what will be done during a particular iteration. Release planning is taking what's been done in one or more iterations and actually shipping.

Why focus on creating working software (shippable software) at the end of each iteration when you are not sure whether it will actually ship or not? A couple of reasons.

Since team members have to make sure that whatever stories (features) they commit to need to be fully spec'd, implemented and tested, they do not sign up for unrealistic goals which is very typical of waterfall teams. Instead, they use real data collected from previous iterations to choose what they are going to work on. This is Yesterday's Weather concept which tells you that the best way to predict what you can do during next iteration is to look at what you've done in previous iteration. No more, no less.

Another reason for striving to create working software at the end of each iteration is to encourage highest level of collaboration between team members. Since the length of each iteration is very short, if you are not talking to each other and help each other from day 1 till the end of the iteration, you won't be able to finish your committed features. No more dev doing their work while QA is waiting.

Being able to actually ship at the end of each iteration is probably added bonus some extremely mature teams can enjoy. But what Agile development want you to do is to set realistic goal and work together to create working software. Deployment is a separate story.

By the way, please don't think that you actually have to have your iteration set as 4 weeks long (what Scrum people recommends). It's completely up to you as long as you don't go too low (less than 1 week) or too long (more than 4 weeks).

Make sure your team is jelled before starting Agile

youngjoo — Wed, 26 Apr 2006 11:05:00 GMT

Agile Development relies heavily on human interactions. User stories intentionally leave out details so that people can talk. Team members sit together so that they can interact with each other always. It emphasizes human side of software development. Software development is an intellectual activity and if you try to put mechanical processes into it, creativity goes out the window.

That's why it's very important to make sure that there's a good team dynamics before starting Agile. If the team is not jelled, I can guarantee that Agile Development will make the situation worse than before.

Here's a quick checklist of things you should consider to make sure that your team is ready. Not a comprehensive list but should at least give you an idea.

How's the moral of the team overall?
Do team members trust management?
Does management trust the team?
Is your team working on the right thing?
Do team members value professionalism?
Do developers understand the value testers add?
Do testers understand the value developers add?
Do team members respect each other?
Do team members hate customers?

Notice that there's no mention of technical competencies of team members. If you have a jelled team, team will together solve that issue.

Book: Refactoring Databases

youngjoo — Tue, 18 Apr 2006 03:22:00 GMT

Refactoring Databases: Evolutionary Database Design
Scott W. Ambler, Pramodkumar J. Sadalage
Addison Wesley Signature Series

If you know who Scott Ambler is, then you definitely want to read this latest book he wrote. If you don't know who Scott Ambler is, you still want to read this book since it's most likely that you are dealing with databases at your job.

I haven't read it yet but just from the title and the cover description, it sounds like Scott has taken his Agile Modeling techniques to next step. After all, Agile Modeling is all about starting from what you know and naturally evolving the database design as new design and architecture emerges.

Ron Jeffrey has a quick review of the book also.

One step at a time...

youngjoo — Fri, 07 Apr 2006 02:42:00 GMT

When I told the team at my previous company that I was joining Microsoft, there were few who showed their disappointments. I was their Agile cheer-leader and they couldn't believe that I chose Microsoft. Why move all the way across the country (NY -> Seattle) to join the company that loves to do things in its own ways and plays deaf when others try to tell how to do it correctly? And that was when Microsoft pretended that they knew what TDD was better than anyone else in the planet.

I had one simple answer to those.

"That's exactly why. Wouldn't it be great if I can help them become more Agile?"

Of course, that's not the only reason why I joined Microsoft. Building great software that impacts thousands of people was something I've always wanted to do and Microsoft was the perfect place to do that. But I definitely wanted to challenge myself and see if I could make Microsoft become more Agile. By the way, I currently do not have any plan to go knock on Bill Gate's door and tell him to understand Agile values and transform the entire company to become more Agile. I will be happy if I can start making small changes and see this company naturally embrace Agile values.

And I have a great news to share with my former Agile cult members. Today, I made my first step towards my goal. A new group called Visual Basic Agile Champ has been officially formed today. The goal of this group is to become a resource for people inside Visual Basic who wants to learn and try Agile values and practices. It's a small team for now (4 including myself). Mike Sampson, SDE, has been working on recommanding process improvements to Visual Basic. Chris Smith, SDET extraordinaire (his word), has worked with Mike on pilot XP projects and had great successes. Stephen Provine, SDE, has a deep passion around unit testing. He has done some great stuff around improving unit testing capabilities in Visual Studio (and I had great conversation with him about Microsoft TDD incident). These are people who want to make changes, who are passionate about helping people do their job better and truly believe that it's possible. I am honored to be invited to join the team.

What's really great about this team is that it has management support. And I know very well what can happen when you do not have a full support from management.

Making the first step is always exiciting. It's only one step but you know your journey has started. Just need to make sure that every move you make puts you one step closer to your destination.

Agile rocks!

[Update] By the way, Mike Sampson is the guy who appeared in Quality Milestone video I mentioned before. He clearly has big interest in this stuff...

Starting Agile? Learn basics first!

youngjoo — Fri, 31 Mar 2006 01:41:00 GMT

One of mistakes people often make when starting out Agile Development is not learning basics. It sounds so obvious. But people miss it very often. Many people who are interested in Agile Development or any kind of Software Developmet Life Cycle (SDLC) improvements already have deep understanding of common issues around SDLC. And that's why they want to improve. Because of that, people think they can skip basics and just learn techniques. This is a dangerous situation, especially for methodologies like Agile where complete mind-set change is needed for successful implementation.

If you are experimenting with Agile, I suggest that you choose one of well-known Agile Development methodologies such as Scrum, Extreme Programming, Feature Driven Development, etc. and FULLY learn it. I would also suggest that you try it out with few pilot projects face-value, word-by-word, without making any modifications to the process. As you learn and try it out, focus on why each practice exist and what values each one provides. Print out Agile Manifesto, put it up on your wall and constantly check against it. Once you've done that, you can start looking at your own situation and other methodologies (even water-fall stuff) to create your own process. Adjust everything to make sure that whatever process you create fits nicely with your organization, culture, etc. You might ask me if I am suggesting that people then also learn all different methodologies fully and try them out before adopting techniques from them. I would say no. All Agile Development methodologies share same values and it's values you are most interested in learning not techniques. So, once you understand one methodology very well, you understand values of Agile Development.

Microsoft Developer Division's Development Processes

youngjoo — Sat, 11 Mar 2006 02:39:00 GMT

Developer Division @ Microsoft is responsible for Visual Studio and it's the division I belong to. Following two Channel 9 videos will give you some peek at the development processes used by the division. These processes are new to the division. Trying to be more agile / scrum, I guess. I will let you decide whether we are on the right track in terms of being truly Agile.

Shoshanna Budzianowski explains how the division is trying to be more agile
Shoshanna (ShoShe) is the Director of Program Management @ Developer Division. This video is not really about the development process but she does talk about it. You can listen to the whole thing if you want but most of development process discussion happens during first 10~12 min. By the way, she was my 7th and last interviewer. I had a great discussion about Agile Development, some challenges people face, things that people mis-understand, etc. It was the toughest one though.

The Quality Milestone
Developer Division just came out of what we call The Quality Milestone. The idea is about taking some time after shipping a major product to get ready for the next one. Some of the big initiatives include getting rid of all bug-debts from the current release (Visual Studio 2005), creating the next generation test automation framework, increasing test automation coverage, setting up continuous integration environment, beefing up the build infrastructure and reviewing the development process and optimizing. It’s all about ensuring that we are delivering the quality software.

You still do not get it!

youngjoo — Fri, 10 Mar 2006 02:38:00 GMT

I wrote about how frustrurated I was with people who abuse the word agile. It's a big problem right now. A lot more people are learning about Agile Development and unless people understand what the real values are, it is possible that this whole Agile thing could fail. People will try it in wrong ways and they will say "Well, I guess this doesn't really work". Arrrggg.

Recently, there was a thread in an Agile Development mailing list about pair programming. One person asked people to give feedback on pros and cons of pair programming vs. peer reviews. Guess what was listed under pros section for pair programming.

Developers don't browse Internet during worktime.

Are you kidding me? What were you going to do with this item? Show this to your development team as a part of benefits of pair programming? And immediately lose their trust? Or hide it from your developers and just show it to your manager? And still lose trust from your team? Are you out of your mind? It gets worse. One person replied to the original message and I found this.

Another benefit of pairing not touched upon yet is the fact that peer pressure will push people to produce and not waste time (surfing the web, taking mental breaks, checking stocks, personal email, etc).

Can you believe it? Put peer pressure to push people to produce and not waste time surfing the web, etc. What a great way to build a team with passion! I am constantly troubled by the people who strongly believe they know what Agile is about but in reality use it as a way to get more things out of developers. Agile does <keyword>eventually</keyword> increase the productivity. But Agile is more about delivering the right thing to your customers in a right way. It's not about using these cool techniques such as pair programming or TDD to push developers to produce more. If you do not change how you think or how to treat your developers and your customers, it doesn't matter if you have a super-duper-pair-programming-TDD-addicted-constantly-checking-code-in team. Agile development is not a technique. It's a culture shock and mind-shift!

Please, get it this time!

* In case you are interested, below is my response to the thread mentioned above.

I know this is a bit old topic but I want to give my two cents about one of the benefits of pair programming listed in this thread.

- Developers don’t browse internet during worktime
- …peer pressure will push people to produce and not waste time (surfing the web, taking mental breaks, checking stocks, personal email, etc.)

If you approach a developer and add this to one of the benefits of following Agile practices, you will NEVER win them over. I believe people sometimes mis-understand the core value of Agile development practices. Making people do more is not the goal of Agile. The core goal of Agile is to develop the right thing in the right way. If someone does a research on time/money wasted by developers browsing the web, taking mental breaks, etc and waste caused by building the wrong thing in a wrong way, I am very confident that the first case won’t even show up in the research paper as a main cause of development productivity loss

Admit it. There is no way in hell to force someone to be 90% productive. You will be lucky if you spend 50% of your time doing actual coding. Writing code is a very intensive activity, especially to your brain. It’s not a mechanical activity. If you sit in front of the computer and code away 90% of your day, everyday, then you will eventually burn out and constantly deliver poor quality code. This is why Agile advocates size-based estimates instead of time-based estimates. It doesn’t matter you spend 10 hours or 100 hours to get something done. What really matters is how much customer value you added during last iteration.

Agile practices solves productivity problem mostly by getting it right the first time and provide an environment to make changes very quickly if you didn’t.

</youngjoo response>

Abusing Agile

youngjoo — Fri, 03 Mar 2006 02:36:00 GMT

I have noticed that more and more people in software business are abusing the word agile. As a person with deep passion around Agile Development, whenever I hear a word agile from someone, my head turns immediately. But I often realize that the word is being misused. I don't mind people using it when they describe other aspects of business but when it's misused while describing development processes, my blood pressure jumps up. Yeah, yeah, I need to be nice to those who are trying to understand it and they will misunderstand some parts just like I did when I first started learing Agile Development. But that's not what I am talking about. It's those who use the word agile but have no intension to change. "Oh, Agile is next cool thing and it sounds very trendy. So I will just use it."

Please do not abuse it. Make sure you know what you are talking about. Read Agile Manifesto and make sure you understand those values. Make sure you are ready to change your behavior and help others to do that. Do not fall back to old habit. Do not think that just using the word in your presentation will get you there.

Please, please, please. Don't give me "We are agile since we have iterations that are short" crap. Water-fall has iterations, too.

Oh, by the way, there is another type of people that drives me crazy. These people think Scrum = Agile Development. Arrrgggg...

Disagree? Leave comments. Offended? Too bad. This is MY blog and I say whatever I want! :)