Leading Agile Transformation

Thursday, August 25, 2011

Did we give up control too quickly?

When I participated in SCRM Master class few years ago I was told that all the “authority and control” has to be given up in favor of Team Ownership, and that there will be no need in management involvement in the development process. I liked the concept of more team ownership and less management control , and I still think it makes sense. However, from observing and coaching multiple teams over the last 18 months I do not think this is a slam dunk. There are several factors that have to be considered:

1.       Team members seniority (experience, technical and product domain knowledge)
2.       Complexity of the project
3.       Novelty of the project (an incremental feature vs. new technology)

What I have found was with lower team seniority, higher project complexity and higher project novelty, the “team ownership with less management involvement” model can break.

Here are some of the consequences of operating in such environment:

1.       Missed design reviews leading to missed functional and non-functional requirements, as well as sub-optimal technical implementations.
2.       Less communication between the team members and the PO, leading to disconnects between them
3.       Misunderstanding of Agile practices and ideas, leading to something that looks like SCRUM from outside but in reality is worse than Waterfall.

It’s true that in the world before Agile we had many problems, but it’s also true that we had some good practices including certain oversight by senior team members and development managers who would help the team to ask the right questions and would enforce some of the practices such as design reviews.

In my opinion each situation should be assessed on a case-by-case basis and certain combinations of projects and teams may need to have a development manager involved during the development cycle, to help compensate for lower seniority of the team and higher complexity of the projects. If the Scrum Master for these teams happen to be a development manager then the risk is mitigated.

Wednesday, April 13, 2011

Are we there yet?

Our entire Product Development organization has transitioned to Agile. Officially. Something tells me that I’m not ready to declare victory just yet. It’s extremely tempting to say “Yes” when people asking me whether we are Agile now. My answer is “we are working within Agile framework” but we are not Agile yet.

All 5 teams are gaining muscle memory, getting comfortable with Scrum terminology, roles, ceremonies, artifacts etc. But how do we know whether we are Agile or if not, what needs to be done to reach desired level of agility? That’s where the assessment comes in.

I’ve seen several approaches to Agile assessments. Ones that I discarded focused on process rather than on results and the end results. Understanding that Agile is the means to an end, but not the end itself I have designed an assessment that focused on Agile values, principles and benefits. The idea here is to observe each team for a period of a single Sprint and interview team members as well as observe the process and evaluate the quality of outcomes. Each team would then receive detailed assessment of their “Agile Maturity” and will receive a list of suggestions for improvements. These suggestions will be discussed with the team and SMART action items will be developed.

The assessment that I propose consists of 6 composite Dimensions:

1.       Embracing change and feedback
2.       Predictability and Planning
3.       Learning and Adapting
4.       Working and Stable Software
5.       Technical Debt Control
6.       Teamwork and Communication

Each dimension has several Indicators with have different weights that are calculated based on observations and interviews (multiple questions/topics for discussions are associated with a single Indicator).

While Agile Maturity Assessment described above is internal to Product Development organization and is a team by team exercise, we also will be performing a Product Development Maturity that will focus on the vision and the goals we’ve set a year ago (see my earlier post about Vision).

Tuesday, March 15, 2011

Optimize (Globaly!)

At this moment we have 4 Agile teams in different levels of maturity. These teams are working on 2 parallel releases. With almost all engineers “accounted for” we saw challenges with triaging smaller projects that do not “fit” the overall theme PO is driving with the Scrum team for the nearest release. These include internal Engineering projects, hot support issues, customer commits, etc. In pre-Agile world the decision was mainly driven by skill set appropriate for the project and the priority of that project relative to other projects. There is no reason why it would be different in Agile, but for some reason it became more difficult to apply the same criteria for decision making. My take on this is before we thought we are making the right calls as far as priority goes, while now we are forced (by Agile process) to have the honest discussion on cross-team priorities and figure out which team takes a hit.

One of the cybernetics principles (that I learned about from Jurgen Apello’s book “Management 3.0”) states that optimizing the outcome for a subsystem will in general not optimize the outcome for the system as a whole. I think this is one of the challenges with Agile transformation: keeping the global optimum in mind while planning the work for the multiple teams. Both Engineering Management and Product Management need to keep the entire picture in mind rather than focusing on themes worked by individual teams. This approach will undoubtedly force discussions with painful decisions, but this is Agile living to it's promise: shining the light on problems in the organization.. It's up to you whether to fix the prioritization and decision making process or not.

Thursday, February 24, 2011

Capacity Planning Techniques

As I mentioned before our approach to Agile adoption has been to go by the book and deviate based on the context at hand later on. One of the practices that we use at Sprint Planning is to calculate capacity at 6 hours a day and load individuals up to 75%-80% of their capacity.

This technique has been introduced by an external coach earlier, and as we begin revising the processes we have, people look for reasoning behind this technique. Surprisingly enough I found that nay people were confused, so I came up with an explanation that at least makes sense to me.

1.       We estimate tasks in Ideal Hours. Ideal Hours are the time required to complete the task if there are no distractions. So, for example a task estimated at 5 hours might take 2 calendar days for someone who is dragged into several meetings, or has context switch to help another developer or pulled into support issue.
2.       When we do sprint planning we compare capacity vs. amount of work that needs to be done in this sprint. In order to compare apples to apples, we have to calculate capacity in Ideal Hours as well. The standard practice is to use 6 productive hours a day for such exercise (I have seen it in references to Agile projects as well as traditional projects).
3.       When a developer calculates his capacity for a sprint she multiplies “days in sprint” times 6 hours and come up with number of hours that can be dedicated to that team in that sprint. If she were to use 8 hours for that exercise she would be allocating a nonproductive hours for actual task work which may not be realistic.
4.       Now, we know that comparing capacity against the amount of work to be completed is just part of the story. This comparison does not take into account dependencies between tasks, the fact that QA are loaded heavily in the end of the sprint, while developers are loaded more in the beginning and the middle of the sprint, the fact that user stories are “negotiable” in that they leave space for making decisions later on during the sprint and therefore new tasks arise during the sprint, the fact that developers are optimistic at estimates etc. If we were to plan for 100% everything would be on a critical path and the slightest mistake would cause user story to carry over. 80% rule creates the artificial buffer that covers for the former items.

Is 80% the right figure for every team? Perhaps not... perhaps each team should determine the percentage that makes sense for them.

Monday, December 13, 2010

Can we scale it? Yes we can!

Any company with enough focus and dedication can sustain a single pilot team. Ok, may be not any, but definitely many. When time comes to scale beyond the single pilot team various organizational impediments become evident and the real test for organization’s ability to go through with necessary changes begins.
Almost every process under the sky has to change and adjust to support multiple teams working on multiple releases simultaneously: Defect Management, Source Code Repository management (branches, builds, etc), UX, Development Documentation (design specs and other artifacts). Before we started with the first pilot team we have identified all these processes and created spin-off teams each focusing on a single process and identifying the way that process would need to adjust to meet the needs of the Agile environment.
The biggest concern with scaling Agile is shared resources: POs, DBAs, Architects, UX Designer, Release Manager, Documentation, and the list goes on. This was always our top concern and therefore it became a prerequisite to scaling beyond the pilot team.
1st shared resource concern that we’ve addressed was a Product Owner role. With Product Managers spread thin already it was obvious that without some scaling mechanism in place the Agile wouldn’t work. We have introduced the concept of Product Owner Proxy to augment the Product Owner role. PO Proxy can be anyone from the team who knows the product well and can make decisions 50% of the time on PO’s behalf and answer team’s questions in PO’s absence. We’ve seen this role being filled by architects, QA and developers in other companies successfully.
2nd shared resource concern that we just started to address is UX Designer. With the constraint of not being able to hire another UX Designer we had to become creative to address this issue. From what we’ve heard from other people it isn’t practical for a single UX Designer to support more than 2 Agile teams. Based on what we’ve learned during the pilot project it became evident that in our environment it will be impossible to support more than 1 team… 1st thing we’ve done was to identify the minimum process changes required to scale: identifying user stories with UX impact in advance so that UX Designer could see 2-3 sprints ahead and know what might land on his plate. Next, we’ve analyzed all the responsibilities and deliverables of the UX Designer and categorized them into 4 categories:
a)Has to be done by UX Designer
b)Can be delegated to another team member under close supervision
c)Can be delegated to another team member under loose supervision
d)Can be delegated to a PO
This analysis has shown that even though UX Designer has a lot on his plate not everything has to be done by him and in many cases can be offloaded even if under supervision to other folks.
Of course it doesn’t stop there: with multiple Scrum ceremonies for each team, UX Designer’s time management will also become an issue. Each organization should identify how to manage that time best with minimum waste on one hand, and without losing the UX insight on the other.
After all, hiring a new resource is not always an option. Even if hiring will have to be part of a solution, in my opinion it makes sense to assume you can’t hire and see what you can come up with. Best ideas come to mind when constraints are present.
p.s. To see how we are scaling the Offshore Manager in the new Agile world read my post at the offshore blog: http://offshoremanagement.blogspot.com/2010/12/streamline-communication-accross-pond.html

Thursday, November 25, 2010

Beginning with Agile in Distributed Environment

Here is my talk at SoftServe Innovations Conference, Florida, October 2010. In this talk I describe our experience to that moment. If you've been reading my blog posts from the last two years you'll hear the real live application of most of the concepts mentioned in my blog.

Monday, September 20, 2010

Daily Stand-ups: Workshop

Recently, after analyzing how we are doing on our daily stand up meetings I decided to run a small coaching workshop with the team. The purpose was to emphasize the value of a daily stand up meeting and figure out how to improve. In my opinion great place to run such workshops is a sprint retrospectives meeting. Everyone is already in the "learning mode" which makes the time right.
Here is a summary of the workshop:

Open the discussion asking the team what value stand-ups have in their eyes. You will be surprised with the answers. Some folks will see certain benefits while others will see no benefits at all.
Ask the team what the purpose of stand-ups is?
Explain that daily stand-ups are for the team to:

Daily sync-up: Be aware of the overall status (what's on track, what's behind, what's blocking, what the risks are, what new tasks were identified)
Set direction and focus
Perform a daily to weekly planning
Share observations on how do our stand-ups look right now (our example):

What I worked on, What I will be working on
Some technical details of individual tasks
Occasional planning during stand-up
Occasional planning post stand-up
Elaborate on how you'd like to see our stand-ups going forward:
A place to self-organize on daily basis: For The Team, By The Team
What I have accomplished since last stand up
What I plan to accomplish by the next stand-up
What needs to happen in order for me to accomplish the task (what blockers need to be removed, what coordination with others has to happen)
This does happen on occasion, so I'd like to emphasize the value of this kind of stand-up.
Problem solving: Parking Lot for post stand-up discussion
Move from "Story telling" to "Headlines"

Next move on to discussing the actual examples. Story telling exercises are the best because they create mental hooks that help people relate to these stories in the future easily. For each example ask the team following questions:

What is good about this stand-up meeting example?
What can be improved?

Examples:
Show
Hide

Monday, September 6, 2010

Complacency is evil

6th sprint is on and it seems like Agile framework is being followed and we are doing everything we should. Every retrospective we identify that one thing that we are going to improve going forward and planning on improving it in the next sprint.

1^st problem we are running into is constant deprioritization of improvement tasks over tasks related to the value bearing stories. The team doesn’t seem to have a problem with it initially as they see delivery of committed story points as a top priority for them during the sprint. The end result is not obvious at first, but few sprints later it becomes more evident: the improvement backlog starts forming and every sprint we have a carry-over of the improvement items.

2^nd problem is an increasing focus on tactical improvements that are the obvious obstacles to progress, while Agile values in general and SCRUM framework values in particular are losing focus and this is not obvious to the team. Our sprints look like small Waterfalls with massive acceptance at the end (usually during the last day of a 3-week sprint) and yet at retrospectives the team doesn’t pick this area as worth improving. Our daily stand-ups are all about the status and slew of technical details, and not about the daily planning. There are some good exceptions, and we do have post-stand-up planning meetings occasionally, but the actual stand-ups are not delivering the value to the team as they should in my opinion.

My plan is to hijack the next retrospective session and run it in a completely different manner. I’m going to turn it to a learning session where we will get abstracted from the tactical improvements and will get back to the framework values and will place the improvements we identify at the top of the backlog. One of the reasons we have got to this point is complacency that we all fall victims to at some point in time. That’s the reason to have a dedicated person (beyond the SCRUM master) to frequently inspect the way teams work and identify these complacency smells.

Monday, July 12, 2010

Knowing the path

In “Made to Stick” Chip & Dan Heath talk about “The Curse of Knowledge” as a term used to describe a situation where a person has a lot of knowledge on a subject, but has difficulty to assimilate it among his peers, or coachees. In “The Matrix” Morpheus and Neo exhibit classic coach – coachee relationship, where Morpheus asks the right questions at right times helping Neo to discover the answers instead of giving them out. During the past 2 years, and especially during last 3 months since the Agile pilot start I have experienced “The Curse of Knowledge” first hand and I saw how difficult it is to hold my tongue when the answer is obvious to me. I didn’t succeed to hold my tongue all the time and it was evident that when I did – the answers took longer to surface, but the effect was great: the sense of ownership and commitment from the group was much higher. It really seems easier that it is… I’m seeing every day my colleagues, whom I would define as excellent coaches, struggling with holding the tongue and rushing to give the answers right away.

With Agile mantra of self-organization, where managers “give-up” the decision making power delegating it to the team, the requirement for this new behavior becomes more evident and we all start paying more attention to the decision making process in the Engineering organization.
Here is an example. In the last sprint we had 3 user stories being worked on. At the sprint planning I have mentioned that the way to attack these 3 stories is one by one and not to work on all 3 at the same time (to the degree possible with all the constraints and dependencies). This idea seemed redundant and everyone was sure that if they work in the priority order of their tasks this will be achieved automatically. Few days before the sprint end the team has realized that none of the stories is likely to make it. This time, instead of bringing this idea up again, I asked few questions that have leped the team to come to this idea themselves. One team member suggested to abandoning the bigger story that had no chance in getting done in favor of other two stories that could be completed with the team effort. Another team member suggested next time the team attacks one story at a time – and this seemed reasonable. Eventually, we’ve attacked the last two stories with as real team effort and got them accepted in time. I could have said “I told you so!”, but this of course would be counterproductive. When the team has come to this realization by themselves they felt ownership of this idea and were committed to try it again in the next sprint.

Tuesday, June 8, 2010

How to stay sane when the world is changing

Agile lives up to its promise to put a spot light on organizational problems and inefficiencies. In our focus group meetings we’ve identified several processes that will have to change once we move to Agile. The discussions on these processes have accelerated with first Agile pilot project kick-off as the new team had to know how to deal with defects, how branches and build environment will support Agile environment, what Definition of Done is and how development artifacts are created an managed.

We approached this by creating spinoff teams that consisted of folks from different teams and locations and were lead by Agile Focus Group members. Each team spend some time on researching their corresponding subject and came up with proposal for next steps. These proposals were presented to Agile Focus Group and actual action plan was put in place. In addition to being very effective way to address many issues in short period of time, this approach presented an excellent opportunity to be engaged in the Agile transformation to the team members who otherwise wouldn’t be involved in the transformation for several months. In addition, the energy and momentum were maintained at high levels, which was essential for keeping the program going at the good pace.

While changes to existing processes will be driven by problems uncovered and challenges presented by Agile, there will be much temptation for modifying the Scrum framework as certain things will not make sense initially.

A word of caution when making changes to the framework. I particularly like the following quote by Ken Schwaber “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it… The intention of Scrum is to make [their dysfunctions] transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them”.

One needs to be careful when considering adapting the framework to their own context. In my opinion, its paramount to keep an eye on Scrum values when making changes, and the likelihood of success will be much higher.

Monday, June 7, 2010

Pattern for Agile Adoption

After leading a transformation for over a year I'd like to make one point. People often take Agile Transformation too lightly and think about it as yet another process being introduced into the Engineering organization. What I've experienced is that Agile Transformation is not much different than any other large-scale organizational change, and as such deserves to be managed accordingly. One has to consider that moving to agile is a significant mental shift in the way people approach problem solving and performing their daily jobs. People that are the core of the change process need to be well prepared and allowed to fail as they learn.
For us it took 1 year from introducing the idea to the management to starting with the 1st sprint. At times it seemed like we are dragging our feet, but in retrospective I can say it was worth investing all the time we spent learning the subject, talking to practitioners, analyzing applicability to our context and identifying obstacles, challenges and plans of attack. This due-diligence has paid off when we started the project.
If I would need to define a successful pattern for planning and managing Agile Transformation here would be the major steps in that pattern:
1. Get a focus group to self-learn Agile. The group has to include at least 1 member from each product development team (dev, qa, pm, ...)
2. Create a shared Vision (see my post “Vision matters”)
3. Focus group meets with practitioners, members attend events and share what they’ve learned
4. Information is digested, obstacles identified and plan of attack for these obstacles being developed
5. Propose a recommendation (go/no go)
6. Get Executive buy-in
7. Start with education for all relevant locations. I've held initial 2-day workshop for everyone, then invited coach to do SM and PO classes.
8. Spinoff teams on obstacles, challenges, processes identified in #4 above.
8. Hire a coach (see my post “Hiring a coach”)
9. Find a good pilot project (it's another topic on how to choose the right one)
10. Have coach facilitate 1st sprint
11. Communicate to the world about the progress

Tuesday, May 18, 2010

When Offshore meets Agile

This post belongs in both of my blogs “Leading Agile Transformation” and “Succeeding with Offshore Management”, so I’ll publish it in both…

When companies look at Agile the question of location often comes up: people are afraid to implement Agile with offshore teams due to the distributed nature of the teams. Of course it’s great when you have face-to-face communication, but I see no problem with implementation of Agile in distributed environment (ok, maybe some challenges).

There was a research done on the subject of communication in different office settings, and what they found is that best communication happens when people are sitting in the same area or in adjacent cubicles. Next best setup is an offshore model and the worst setup is when people are located in the same building but not in adjacent areas. The difference in communication efficiency was significant between 2^nd and 3^rd categories, but insignificant between 1^st and 2^nd. One of the reasons for these findings could be that people in the 3rd category think they are collocated and do not need to invest in improving communication channels and communication efficiency. On the other hand, folks in distributed setting are well aware of the challenges of communication and are investing a lot of effort in constant improvements.

Agile fosters frequent communication and helps distributed teams to advance to the next level of efficiency. Yes, there are challenges that are exacerbated with Agile: more communication requires more discipline and sometimes changing the ways we communicate and may require additional tools to support it. This is not different from any other problem that Agile helps to put a spot light on and that requires resolution. Agile will emphasize what we as an organization need to focus on to make sure required communication levels are met.

One thing we’ve been struggling with before was choosing the right timing for onsite visits: the environment was pretty chaotic and it was difficult to plan for a visit and to tie it to a certain event (planning/design review, etc). With clarity of SCRUM it’s obvious how we can leverage the framework to plan for visits: Release/Iteration planning and Demo sessions are a natural fit for this.

As part of our Agile transformation I’m making sure to have not only Agile enthusiasts on the other side of the ocean, but someone in coaching capacity to augment my efforts on site and help teams when I’m not available due to time difference or any other reason.

Monday, May 17, 2010

Learning Pays Off

There is no entry in this blog since December ’09 not because I was lazy, but because so many things have happened in context of our Agile Transformation, that I decided to wait and organize my thoughts.

In February I’ve held a 2-day offsite workshop for the entire Product Development team. It was a workshop and not a mere PowerPoint overview of Agile practices. We’ve analyzed our challenges, our vision and goals, learned through games and read articles about Agile adoption. We’ve discussed success factors, success criteria and recipe for failure. This was my first public speaking in front of such a large audience for such long period of time, so as much as it was educational for the entire group it was quite an experience for me as well.

It was extremely beneficial to walk the entire team through the vision and the goals and showing how with help of Agile we can get there. Once the group understood that we are not doing Agile for the sake of “doing it”, but Agile is just a means to an end everyone became more comfortable with the idea of adopting it. Especially it resonated with senior engineers, some of whom had pretty bad experiences with Agile in previous jobs, where Agile was shoved down the throat by the management. Everyone has appreciated the fact that we’ve learned Agile for almost 12 months and didn’t want to rush with it right after reading a book.

Armed with the basic understanding of where we are marching to and how will we get there we had additional onsite education for Engineering Management, Product Management and key engineers on the roles of Scrum Master and Product Owner. These were lead by external coaches. Not to forget about our offshore team in Ukraine, we also made sure to organize SCRUM training over there (some delivered by me, and some by local coaches).

As our major release was coming to an end we were at the right place as organization to begin our 1^st pilot project.

Wednesday, December 23, 2009

Executive Commitment

“Is Commitment a direction to be pursued as long as it works for you or a direction to be pursued until it works for you?” –Anonymous

Getting executive commitment is crucial for Agile transformation success. The process is long and road mines will await you surely. It will be of utmost importance to have the executive team still supporting the initiative when things get tough and the pressure to get product out increases.

I have found that it’s not hard to “sell” Agile to the executive team: what is there not to like? The value proposition of Agile sells itself and all CEO hears from others outside the company is “you have to go Agile”. So on the face of it everything looks good and executive team is all in agreement that Agile is the way to go.

When I presented Agile to execs few months ago I took a different approach. Well, I had to do the selling part, not without it, but most important I have described all the challenges and obstacles we anticipate having in our way to become Agile:

1. Shared resources (PO/UxD/Architects),
2. PO availability to the team (considering other responsibilities of Product Manager)
3. Leading virtual teams
4. Too often/uncontrolled changes in direction
5. Inability to decide on priorities in timely fashion
…and the list goes on

One thing Agile does quickly and without a facelift is exposing existing problems in the organization, and when a company embarks on Agile transformation path these problems have to be dealt with, breaking status quo and being painful to resolve at times. For example, if the company has a problem on deciding on priorities prior to Agile, the problem will not be resolved just by going Agile. Agile will show the way if you will, but the company will have to address the issue immediately.

Although I still got a green light from execs, the real test of executive commitment will be when the push comes to shove.

Monday, November 9, 2009

Vision Matters

"Would you tell me, please, which way I ought to go from here?" [asked Alice] "That depends a good deal on where you want to get to," said the Cat. "I don't much care where--" said Alice. "Then it doesn't matter which way you go," said the Cat. "

--Lewis Carroll, Alice in Wonderland

It's easy to become cynical of company’s vision or mission statements: they usually sound either a mouthful that no one can understand without a transcript or too “motherhood and apple pie” that no one can relate to. Yet, vision matters. If you don’t know where you want to be, how can you prioritize and make decisions along the way? And… by the way… along the way WHERE?

Take one of the most successful companies you know and try to guess what their vision is. You might not guess the right wording but I bet you’ll get close. The reason for that is simple: these companies got THERE by taking specific actions and making specific decisions that have aligned with the company’s vision and brought them closer to achieving it.

Having a vision is crucial – everyone in the organization has to know what the desired end result is and why we are going through this transformation. When a decision has to be made, an approach chosen or a conflict resolved, having vision will be a guiding force for you. Test your decisions binary, in a vacuum: will it bring you closer to achieving the goal or not? Then add the context.

The vision format that worked great for us was one we borrowed from Coca Cola:

Our vision is: [A high level statement goes here]. In order to achieve this vision we’ve set clear goals:
[Supporting goals go here.]
This format allows avoiding a mouthful by stating one short summarizing statement and “delegating” details to the goals. Next key point is for goals to keep good balance between being too concrete vs. being too general. At this stage do not plant Agile concepts in, remember – Agile is a means to an end, so concentrate on an end when composing a vision statement.
Next comes not less important part – planning for communication. While freshly created vision statement resonates well with all the participants in long brainstorming session, you should expect that coming out of that meeting your vision statement might not be as clear to the rest of the group. For each goal provide meaningful explanation in simpler terms and list everyday activities that will help you achieve this goal. These will not appear on the vision statement poster, but will be communicated by you to the rest of the group.

Many researchers in field of leadership have concluded that vision is one of the key components that a true leader must possess. While having a vision statement does not make you visionary in one day it does help motivating people around you, and in Agile transformation you’ll need it.

Tuesday, November 3, 2009

Hiring a coach

Agile coaching is a hot topic now – great opportunity for anyone who is in software or management consulting business to capitalize on on this new “trend”. How do you choose a coach that is right for you? To answer this question let’s focus on what we are trying to achieve. We need a coach to accompany our Agile transformation because we do not have enough expertise in-house – sounds like a good reason to hire a consultant. Our initial thought was to find a coach who has “done it” with companies of our size and with similar transformation context. We were focusing on challenges this coach had with other teams and whether he/she was successful to address these challenges, and how creative he/she was in addressing them. Here are some good questions to ask the candidate:

1. How would you address the limited shared resources situation, knowing that company cannot hire additional personnel? Specifically, how would you suggest dealing with 1 UX Designer serving simultaneously 3-4 teams? How about Product Owner serving 2-3 teams?
2. Pure SCRUM promotes approach of evolving architecture, while focusing on juiciest features. This is one area where we will not follow the guideline and would take RUP based approach, investing in architecture in the beginning. How would you approach this kind of projects, knowing this constraint?
3. Would you engage offshore team in pilot projects? If yes, would you try to co-locate or to mix teams (current model is mixed/extended teams)?

Like with hiring any senior resource it’s important to look for behavioral patterns through thought process exposed while answering the questions.
Another important aspect that we felt was necessary is coach background. It’s definitely an advantage when the coach is coming from development background experienced in both Waterfall and Agile environments. This is because there will be a higher chance to ”click” with engineers on fresh Agile teams.

Friday, October 9, 2009

Ready? Set Goal!

For task force to be successful it has to have a clear goal. The goal is to assess feasibility of the change. This means the group will need to answer following questions:

Can agile address our problems? Remember, we are not doing the change for the sake of the change.

Are the benefits tangible? You should be able to look back and show that specific problems got addressed and you better off than you started.

Do benefits outweigh risks? Agile transformation is a change like any other organizational change, you should expect turnover associated with it, going slower before going faster and need to consider that many companies fail attempting to make such change.

Should we go by the book or pick and choose specific practices? There will be people (yourself included) who will be tempted by such approach, as it seems to mitigate some risks, but this needs to be carefully studied.

It’s important to understand that Agile is not a one size fits all, so no prescriptions for success could be found in the pure theory. Any organization attempting Agile transformation needs to become creative about addressing many challenges awaiting it. One great way of becoming creative is engaging with Agile practitioners and coaches, learning about their challenges and the ways they have addressed these challenges. Of course their situation and context could be very different from yours, but learning from their successes and failures could be very helpful.

Friday, October 2, 2009

Task Force (or "Back to School")

Congrats! You’ve found the right time and convinced your boss that the change is needed. What’s the next step? Ideally you’d like to have the entire Product Development organization buy in to this idea and start implementing the change right away. Unless your organization consists of two guys writing software in garage, this needs to be carefully planned. Good place to start is to create a task force: a group of people that would learn about Agile methodologies and frameworks, will meet with Agile practitioners and coaches, will assess the feasibility of applying Agile to your organization and will recommend a course of action for the company. There are few key factors to the task force’s success. First, you need to have representation from all the groups primarily affected by the change (Product Management, Development, QA). As you select task force members try to include people who may resist the change the most and are key to your organization (senior managers, key engineers etc). Change initiatives, as just as they could be, may cause higher rate of turnover and no one wants to lose key talent as the change is being implemented. Having key people and potential resisters on your team will help guarantee the success of the transformation to be. Next, make sure that you include people who are seen as leaders in their respective groups and would be able to communicate the vision and help get buy-in to the change. In general, smaller teams will get things done faster, so team of up to 5 people should suffice.

Good task force should have pre-defined goals, timeframe and approach for achieving these goals.

Tuesday, September 29, 2009

Failure? To Launch!

Sometimes we read or hear about some new direction in the way people do business and tell ourselves: "Only if we could implement this in our company!". Then we rush implementing this new way of doing business at 100 mph and find ourselves in worse spot than we started.

So how one makes the change, if he/she feels strong that this change is a must?

Well, one of the obstacles is awareness of the problem that the change needs to address. After years of doing things certain way many people might become blind to the root cause of problems they constantly facing and assume that these problems are inevitable. This leads to attempts of patching the current processes and creating new processes, often adding significant overheads but not addressing the core problems. Surprisingly (or not so…), this approach is usually acceptable by most stakeholders as it is associated with much lower risks than the complete makeover.

First step in any change initiative is raising the awareness of the problem and the urgency for a change. Now, no one will ever bless a change initiative if the sole reason for the change is making the change. Unfortunately, in many occasions a “systematic failure” needs to occur for everyone else to see that they way things are being done now cannot scale and for the company to thrive, change must happen. At that point people might not know what exactly needs to be changed, but they already know that they cannot continue doing business as usual. For the change evangelist this creates an opportunity not to be missed.

If not successful otherwise, use the momentum of the “systematic failure” to raise the awareness of the problem and urgency of a change. Your management will gladly let you lead the task force charged with analysis of the current methods and proposal for the change.

Search This Blog

Blog Archive

Labels