Has the Agile World moved on?

Tough question. As I write my first post on this blog after a long long time, I wonder if the world has actually moved on? The misinterpretations, myths and downright abuse is rampant and the bright spots few and far. I teach, guide and coach young and experienced teams. Because of my work, I also get the opportunity to meet some really bright software professionals – some who have considerable experience with software engineering processes, including Agile. Some recent conversations in some of India’s (and world’s) top companies around agile practices were like this.

Beginners:

• It means too much pressure.
• It means micromanagement.
• Our company is too unique for this.
• Are testers going to be out of the job?
• Does it really work?

Intermediate:

• Our product management sucks.
• Why are we forced to enter details in an electronic system?
• It is not as cool as it is made out to be.
• How do you get anything done really?
• Does it really work?

Advanced:

• Agile is not the answer.
• Processes need to be customized.
• You need the help of a software coach.
• Process without engineering excellence does not work.
• It depends.

That’s how it is now. That’s how it was years ago. Agile is now talked about by more people and in more countries but the rise has not been exponential. Is this because Agile has still to figure out challenges like scaling (SAFe and others are trying), real-time support (Kanban) and aligning the organization (Lean)? Or because, Agile starts as a destination but ends up becoming a journey, sometimes tedious and many a times, one with cross roads that take a while to figure out. Or maybe, I am not exposed enough. It is exciting to resume writing again.

Product Manager 2.0 – New Course I am Working On

I currently work as a Product Manager. My last job was a Product Manager. The one previous to that was a mix of Project Management and Business Analysis. I have been an Agile and Scrum fan for a very long time now 🙂

One area where enough coaching is not available is the role of Product Manager/ Product Owners in Scrum and Agile world. I am compiling a slide deck talking about this. I’ll also think of exercises, theory and examples.

Whatever conference comes up next, I’ll try and schedule this talk there!

Any links, examples – will help!

——————————————–

Here is what the outline looks like:

• What is changing about the way products are developed? -> Internet times, Marketing changes, Hardware upgrades, Customer preferences, Increased competition
• What is changing about the way products are supported and marketed? -> Social communities on the web, Instant gratification, Thought leadership
• What is changing about the engineering teams? -> More involvement in product strategy and support, Better work-life balance, Increased communication demands, More informal structures
• A bit about Agile and Scrum
• What does a traditional Product Manager do?
• What changes now?
• How to gather requirements?
• How to write requirements?
• How to prioritize?
• How to work with engineering teams and testers?
• How to work with marketing, support, sales, PR?
• How to work with senior management?
• Skills required!

This is still a bit hazy. Let’s see how it develops 🙂

How to Prioritize Requirements YouTube Video

I have written about how to prioritize before:

• Prioritze tasks for web and software development : Issues

As Agile Product Managers, you are constantly prioritizing requirements to get higher value items out sooner. One approach I saw recently, seems very promising. Here is the video. Go ahead and watch it.

Basically, divide your requirements into four quadrants with Y-axis being Business Value and X-axis being Complexity. Hence, you would ideally do quadrant number 1 first and quadrant number 4 last. You can take a call between quadrant number 2 and quadrant number 3 – depending on what your current business strategy/ pull is. Simple. Do it over and over again and we will always provide higher value first.

Team Leads or Project Managers as Scrum Masters

In organization after organization, transitioning to Scrum, you see one common pattern. The pattern has existed for at least 03 years now. The pattern is seen in all organizations [at least in India] – established big names as well as upcoming talked about/ blogged about startups. There is a team and there is a Product Owner [or Manager]. So far so good. There is also a Scrum Master – who is also the Project Manager/ Development Manager/ QA Manager/ Program Manager/ Project Lead/ Team Lead/ Developer/ Tester. This raises some questions.

Why is this happening?

I haven’t quite figured out [as yet] why if you are transitioning to Scrum, would you want this to happen – especially when Scrum Master is defined as a full time role in Scrum. The feedback I get is mostly around these lines:

• There are not enough Scrum Masters available. We can’t just keep waiting for them to turn up. Hence, we identify people internally who can play this role. And, no one wants to do this role full time or take on this title officially. So, there we go. Do your 2 plus 2 is 4.
• There does not seem to be any value in this role being a full-time – it is something you can do part-time. How much time can removing obstacles for the team actually take?
• Serving the team, Protecting the team, Helping the team, Guiding the teams use of Scrum is something, which everyone should do and different people are already responsible for these things.

It is easy to dismiss or scoff at these [especially the latter], but these arguments actually seem to be true. I know for a fact that there are not enough Scrum Masters available [possible topic for another blog post]. I also know, that in an organization internally, not enough people are kicked enough to play this role. And, no matter what argument you give, the management is never convinced that this can be a full-time role especially when they see others doing this role.

Is this a good practice?

My views on “doing something just because ABC or some book or some user group discussion says so” are well known. Don’t do it. It is also said, that having no Scrum Master is better than having no Scrum Master. Before we address the question – Is it a good practice for Team Leads/ Project Managers/ Developers to be also Scrum Master, we must see what is it that a Scrum Master does. Like most things, lets start with Wikipedia, “Scrum is facilitated by a ScrumMaster, also written as Scrum Master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverable. The Scrum Master is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master’s role is to protect the team and keep them focused on the tasks in hand.” Scrum Masters use soft power, servant leadership and trust to help the team become better. Scrum Masters also surrender complete control to Product Owner and the Team.   Some of the qualities we look for in a Scrum Master are humility, staying in the background, integrity and gain trust. We obviously see the clashing red flags here – the Scrum Master is not a leader. However, typically, the Leads/ Managers are that. The team is reporting to them. However, nothing that we talked about in Scrum Master’s role says that you can not have that with the team reporting to you or you working part-time as a developer/ tester. In fact, some people could argue otherwise. If you are a developer and you are convincing everyone to test, you can lead by example. So, let me stick my neck out and say – “I don’t think it is a bad idea.” It is always better to get the right person play a Scrum Master – like role half time than getting no Scrum Master or lousy full time Scrum Master. However, I won’t probably call them Scrum Master. I’ll call them Scrum Evangelist or Process Owner or Scrum Owner or something like that. Why a different name? Because, the team does not report to Scrum Master [yes, just because of that]. And, anyways, it wont be the name, but the intent and the action of the person that will play out louder in the transition scheme of things. Also, you should get these people [and the rest of the team and Product Owners] good coaching.

Some of these people [Process Owner or Scrum Owner] will make Scrum a bad word in the organization. But, so could many Scrum Masters and Product Owners [and even the teams for that matter]. The hope is that organization will pick the right people for this role. Like the rest of the organization, these people [whatever you have called them] will also transition.

Have you gone Beyond Agile Yet?

Modern Agile. Post Modern Agile, Post Agile, Beyond Agile, Agile 2.0. Buzzwords 2.0 are flying right, left and center again. At conferences, at workshops and at twitterverse. This at a time, when people and companies, are still getting used to decentralizing and moving faster. But, do we need another movement, another thought process – at this time

Part of Agile’s [or agile’s] philosophy is “inspect and adapt”.  Agile is basically the agile manifesto and the values. I read the manifesto and the values many times over : whenever I am confused, whenever I have a question or whenever someone tells me that what I am doing or saying is not”agile”. From the clutter that surrounds discourse around Agile 2.0, the one clear voice seems to be that it depends : “You should be able to question the values too.” Being liberal at heart, I will concede that. Let us look at some values and see if you could do away with the values as such.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. There can be situations where “continuous” is not relevant and probably “early” in not relevant either.  Where exactly? For instance, in a financial application where tax laws are changing 3 months from now – you want to make sure you work towards that rather than focusing on early delivery [before the laws change in bits and pieces or focusing on usability releases while not having time for migration issues at the end].

Welcome changing requirements, even late in development Agile processes harness change for the customer’s competitive advantage. Ok! when you will word the last part of the sentence the way you have worded – pretty much no one will argue against it. However, the same phrase also means that you want to welcome changing requirements because it “can” lead to customer’s competitive advantage. What if it does not? What if its jut a whim of a product manager? What if it delays launch by a few weeks? What if the impact of change is not fully understood?

Just two examples and the generally dismissive note that people ascribe to post modern agile starts appearing like a judgment pronounced a bit too early. But 1+1 does not prove things sometimes. Hence, let us pick from the manifesto itself. The manifesto reads:

• Indivuduals and Interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

As much as I think and re-think, I can not fault any of these above, in any context if I take out the mean and wicked sense that is. However, there maybe a need to be street smart in some situations. Hence, you want to make sure that your contracts are negotiated well even if your customer collaboration goals are high. Similarly, comprehensive documentation might be required in an outsourcing context. Responding to change vs. following a plan depends where you are. Too early in your product development, changing things frequently could result in chaos. And if your software team is fixing support bugs all the time, processes and tools might take precedence over interaction. The context varies and hence, your values would vary too. The keyword here is “context”. You might have to look beyond Agile Manifesto/ Values sometimes. Is that a radical thought?

I guess if we renamed everything to “contextual” software development or “contextual” management. Or, maybe this sounds creepy. Let’s just say Agile [consider it as an umbrella term] is one of the option available. The key is to realize that Agile [and not agile] is “one” of the option and “not” the option.

Agile Mumbai 2010 – A Review

It is difficult to review a conference objectively, if you are also a volunteer organizer. Also, most of the people who were other volunteers are people I meet daily too. I will try.

First of all, I must say that this was definitely the best Agile conference I have been to. It is right at the top in my list of best conferences as well. There was a strange fluidity to the way the program went – there was hardly a moment when nothing was happening – one talk followed by another followed by activity followed by discussion followed by more talks and so it continued for the 2 days. It was also one of those conferences where the things just kept getting better. The best part of the conference was the intimate and close [and refreshingly candid] Q&A session with the 4 Gordon Pask Award winners. The food was nice and the breaks were lively with people coming together in huddles and discussing their experiences. I am sure every attendee went back with new acquaintances. We had a hard time bringing everyone back for the talks and once a speaker had to actually go to the tea break venue to let people know that his talk was starting. “Discussions” – that was the key take away from this conference. Unlike previous conferences, where most of the audience fell mostly into two slots:  skeptical or zombie; here everyone was brimming with ideas, thoughts and opinions. Probably, years of implementing Agile have now given the community a voice and the voice a community.

My thoughts on the talks I attended:

• Outside the Code: Using Agile Ideas to Drive Product Success by Jeff Patton: This was a good start to the conference. Jeff Patton started the conference by focusing on “Product Success” and doing things which can help discover, identity and lead to success. Some of these things are not even related to coding. I thought this really set the pattern.
• Monkey See, Monkey Do by Naresh Jain & Sandeep Shetty: I thought this was the best talk of the conference. It came from the heart and I liked it how Naresh was being provocative and Sandeep tried to then temper it down a bit 🙂 I liked the provocative part of it – at presentation was WTF [way to fail I mean :D] but after about the first 30 minutes, everything started ringing a bell and then it was belling all over.
• Adding Sanity to Your Agility: Doing What Works Over Doing What You are Told by David Hussman: David touched on several examples of how doing something that experts tell you, can be doomed. As he told story after story, you could see nodding heads in the audience – almost confirming what they have been waiting for someone to confirm. David also has a nice way to simplify what could be radical thoughts – to an extent, that you treat those as obvious and not radical.
• Analysis Anti-Patterns by Tarang Baxi from Thoughtworks: Excellent. Each of the patterns came from experience and not from text book. They even challenged the audience to come up with names for some anti patterns [and there were gifts too]. I thought this was nice and the second best talk of the conference for me 🙂
• Transcending Cultures, Timezones and Countries by Mahesh from Thoughtworks: Mahesh was patient and methodical. I thought he could have moved a bit faster, but it was a nice compilation nonetheless.
• Using ToC and JIT to coach Agile Teams by Naresh Jain and J.B. Rainsberger: Sometimes college professorial, sometimes challenging and sometimes corporate workshop-like, this was one talk that had it all. I was a touch disappointed because it deserved more time. Maybe, next time they can do this over 2 consecutive sessions. However, what we saw was nice – practical to the core.
• Stop It Or I will Bury You Alive In A Box by J.B. Rainsberger: This was another of the “shake you to the core” talk. I liked aspects of it, did not agree with others – but it was definitely the most energetic and lively talk of the conference.
• Evolutionary Architecture and Design by Pradyumn Sharma: A simplistic and effective presentation for beginners. I thought there could be more depth, which I am sure would be added by the presenter for his next talk, based on Q&A round at the end of the talk.

I loved Programming with the Stars. It was fantastic. I thought all the teams were very brave and judges were honest and cool at the same time. Bengaluru promises to be even more fun 🙂 Unfortunately, I did not attend any of the product demos. I don’t think they are recorded either. The sponsors : Xebia, Thoughtworks and BNP Paribas, participated enthusiastically in the conference and it was good to see actual people from sponsors rather than just their boards. As already mentioned, the panel at the end was superb. Topics like “Do employees really care about Agile”, “What do you think about Director of Agile Software Development titles”, “Are story points scalable” and “Is TDD for everything” started great discussions.

P.S. One of the highlights of the conference was the talk by Captain Planet. It was short, compelling and insightful. I am switching off one monitor already, abstaining from plastic and trying to do my bit by walking as much as I can. Do your bit too!!!

Agile India Conferences at Mumbai and Bengaluru – Program Updates

If you haven’t already heard about Agile India [ASCI] conferences at Mumbai and Bengaluru : Jan 16-17 and Jan 22-23 respectively, then you can find more information about them here: http://www.agileindia.org/agileindia2010

I was looking at the Program Agenda in the conferences and it seems like these are heavily oriented around People and People Management. There is only one direct topic on Product Engineering on one/ more of the many popular engineering techniques.

Let us look at the Mumbai conference:

• Jeff Patton, is a renowned figure in Agile Product Design. He would be delivering KeyNote 1 on the topic: Outside the Code: Using Agile Ideas to drive Product Success. As a product manager, this seems like a great topic. Excited 🙂
• Monkey See, Monkey Do : [earlier titled a bit more provocatively] : promises to be a provocative look at the world of Agile coaching/ experts and even some practices. Go in, with no expectations and be surprised [or startled :-)].
• Getting Ready To Produce – What is Needed Before Iteration 1 is a great topic and would definitely be helpful to all the teams. I know this, because a lot of teams ask me this question all the time.
• Continuous Monitoring (for Continuous Improvement) is another excellent topic and something that all managers would love – how to track/ meet tracking requirements
• David Hussman, another renowned figure would be delivering Keynote 2: Adding Sanity to Your Agility: Doing What Works Over Doing What You are Told. Humn! Go for the speaker and not the title. You will benefit for sure 🙂
• Analysis Anti Patterns, a great topic [and rare to see Analysis topics in Agile Conferences]. I am sure it would be a must for all the BAs and PMs out there.
• Agile Adoption with Augmented Distributed Team for developing on top of existing application, is a heavy duty title and also a case study. Hence, this would really be exciting. I am sure everyone who works with distributed teams would take back important tips.
• A Critical Look at CMM and Agile Through Gen Y is a talk I am looking forward to personally. The title says it all and working with Gen Y for many years now, I think I can do with all the tips anyone can share.
• Scott Shaw, kicks of the second day with Lean Concepts for IT Professionals. With everyone focusing on “Next Generation Agile”, it is good to go back to the basics.
• Using ToC and JIT to coach Agile Teams is for all the Agile Coaches and would be coaches.
• User Story Mapping is the second topic focused around planning and analysis. Again, would be useful for anyone involved in planning, estimating and analysis.
• Test Automation strategies for Agile is the only engineering related topic in the schedule. And probably the most relevant one too.
• Agile Fiascos – Art Gallery is the second most awaited talk for me in the conference.
• Agile Adoption Failure Modes is for you if you are into a few years of your Agile adoption. It might just hit a nerve or motivate you or do both.
• Evolutionary Architecture and Design just about sums about the Product Design/ Analysis theme perfectly.

Some of the above talks are not featured in Bengaluru. Analysis Anti Patterns, Test Automation Strategies for Agile, Lean Concepts for IT professionals and Evolutionary Architecture and Design are not there in Bengaluru. However, they have some exhilarating talks nonetheless.

• Facilitating Dialogue in situations of Conflict is an excellent topic and I am already feeling guilty of not being there to hear this talk.
• Cultural Challenges in Global Agile and Offshore Agile Challenges and Mitigation Strategies are excellent topics too – more focused and would definitely be interesting to listen to.
• Breaking the Monotony – another one that hits the nerve : pertinent to the core.
• Babysteps to Agility by Jann Thomas is perfect for everyone still looking for a buy-in : inside them or outside them.

Above all, I think it will be great in both the locations, although I will want to be at Bengaluru too 🙂

Good Enough Software Does Not Mean Bad Software

Software to be released should be just “good enough” and not perfect. You hear that a lot these days. “Good enough” from whose perspective? From the perspective of people who release software or from the perspective of the people who will use software? If it is latter, then who decides what comprises “good enough”?

The thought for this post came from one of people I follow on Twitter @enkerli. In the time I have known Alexandre, I have found him to be extremely patient [he is a teacher of repute and of some experience too]. Yesterday, he tweeted -> “enjoys draft æsthetics yet wishes more developers would release stable products. / adopte certains produits trop rapidement.” You can not but realize that he must have signed up for some web application [we will be using web application scenario in this post] expecting the best, only to be let down by an application where either things are either not there or just do not work. Personally, this happens a lot. I type out the web address of this supposedly great web application after reading a review, blog post, news article – and immediately see tonnes of HTML issues – inconsistent fonts, links not linked [with a # key that seems a favorite of development teams these days], pages that are under construction [with no dates of when you expect these to be working], server bandwidth issues [with web applications unable to handle a few thousand users], forms that won’t submit no matter what you do, pages that go haywire when error messages appear at the top and emails that confuse you further. It is almost as if the teams are not asking if it is “good enough” but even if it is “bad enough”, we can always claim that this is “good enough” for now, more is coming later.

I understand the rush of releasing now than tomorrow, why teams would want to adopt this. If you see lot of people using your application, you know the major risk “Are we building the right thing the right way” is minimized. Further, if the major feedback is on product direction [what the heck is this, abandonment rates are high, XYZ do this better], it is nice to be able to figure out these issues sooner than later. There are multiple ways of checking that [for instance focus group meetings, stakeholder meetings, exclusive previews and private beta]. Probably, like all things that mean no harm, “good enough” is being used by people in a way that suits them. Hence, it is important to understand what exactly “good enough” means. One of the good definitions of “good enough” can be found here. It is more a measure of software quality [and code] – simple, correctness, consistency and completeness. Another good definition can be found here: good enough software is the best software we can write given all the external constraints (money, time, resources, inadequate information, etc) placed on us. It’s certainly not the best software we can write before we clock out to go see our son’s ball game or the best software we can write because we don’t understand the problem space and can’t be bothered to ask. James Bach of Satisfice Inc. describes “good enough” software as making rational choices in the face of market-driven projects. The idea is that it’s okay to ship with bugs as long as you ship with the “right” bugs; that, given enough benefits, the minor problems will be overlooked. You have to be able to distinguish between important and unimportant, necessary and unnecessary. According to Pete McBreen, “The decision to ship is based on the risk of shipping a software product that will be seen as low quality. Once that risk is low enough for the organization, the software is good enough to ship. Conversely, if there are not enough valuable features in the software, even if the defect count is zero, the risk of shipping is too high and the software is not good enough.”

Now, that we saw that “good enough” is not a cosmetic 2 minute pop philosophy concept – the next argument would be “it takes time to write such a software”. Yes, it does. All software needs time to think and write. How much – depends on competence of the people. Like most things Agile, it takes maturity and courage to accept shortcomings to write software that is “good enough” – in a true sense.

Agile India 2010 – Mumbai [Jan 16-17] and Bengaluru [Jan 22-23]

Agile India, is organizing Agile India 2010 Conference in 2010.  It is the first two day conference from Agile India and would be held back to back [consecutive weekends] as below:

Mumbai, Jan 16-17 at Narsee Monjee Institute of Management Studies

Bengaluru, Jan 22-23 at Symphony Services

You can find more information at the Agile India 2010 Conference Page [more information coming soon, but if you are interested to speak at the Conference then see here : http://www.agileindia.org/agileindia2010/agile-india-2010-proposal]. The conference tentative schedule would be up soon.

Product Vision : The Key Role and Responsibility of Product Owner

Continuing with the discussion on Product Owner role and responsibilities, and based on two excellent comments from Martizza and SJJH, let us review the key role and responsibility of the Product Owner. One can argue that the four skills/ competence areas highlighted in the Who can become a Product Owner post along with people management and interaction skills, help the Product Owner articulate, defend and refine the Product Vision. One can also argue that this is a separate skill and competence area and some people can just be better at this job even if they do not have the domain knowledge, are not technically sound or have the necessary experience. What will these people then typically possess? I think it would be a mixture of ability to learn [learn very fast], a highly analytical mind [capable of drawing analogies], intuition [strong emotional connect with real and abstract] and a thinking mind [one that can think even when it does not know it is thinking]. These people would generally believe hopelessely in what they are working on – and it is this belief and the conviction that helps them exude the product vision. Hence, when one is looking to appoint or hire someone for Product Owner position, one should see if they identify with the product and what are the ideas they bring to the table. If the connect is established, the rest of the work would flow a lot better.

So, what exactly does a Product Owner do with the Product Vision. They do 03 things:

1. Define the Product Vision – This involves close connect with the customers and market needs. Hence, domain expertise and exposure to tech support/ marketing comes in handy. Further, exposure to some sort of modeling methods helps the Product Owner define the product vision. Often, the Product Vision phase can take long. As a Product Owner, you may consult other domain experts, technical team or embark on marketing feasibility studies to confirm and reconfirm the vision.

2. Articulate the Product Vision – This is more important than 1. Typically, the Product Owner should be available to the development team anytime and everytime. The Product Owner should be able to sit down with different team members – together, in groups or alone – and discuss aspects related to the product – what will happen in 02 years, 02 months and what do they think could happen. This helps build the trust and orients the developers from a Product Owners perspective – a key requirement to build a great product. One of the means available with the Product Owner, to articulate the Product Vision is Product Backlog and ceremonies like Sprint Planning, Sprint Review help achieve this too.

3. Refine the Product Vision – Each time the Product Owner meets people from marketing, sales, technical support, development team, testing team or customers – they will keep uncovering new things about the product. It could just be new technology [Google Wave was launched a few days back for instance] or a new trend [micro-blogging and social media]. This can represent opportunities or threats. Product Vision is not stagnant. It is dynamic.

If a Product Owner can take care of the Product Vision, the Product would largely take care by itself.