You need to talk with real users in order to build good software
Apr 12th, 2012 by Joca

I was reviewing ThoughtWorks latest version of their Technology Radar, which is a great source of information to help you know what’s hot in terms of software development and IT management, and notice it doesn’t mention Product Management (or you can call it Product Ownership) and put Experience Design (XD) only at the “assess” sector of the technique area of the radar.

In my view, Product Management and Experience Design are techniques as critical to successful software projects as DevOps, Continuous Delivery, Testing, Agile and Lean.

  • Product Management role tells what needs to done and in what order.
  • Experience Design role tells how what needs to done should be done, from the user experience perspective.

It is quite difficult to develop good software without those two roles and their techniques. Both should be in the “adopt” sector of the technique area of the radar.

Product Management is not only for systems that will become a product, but for any system, since any system will have users. The Product Management role is the link between system users and the team who will build the system. It is different from the Business Analyst role which is more focused in the business and the owners of the system. And its different from Experience Design role which is more focused on how a user interacts with a system.

The Product Management role is responsible for talking with real users of the system, understanding the pain that the system is supposed to solve for these real users and help define what needs to be developed. Note that a system may be owned by a company, like a ticketing system or an ecommerce system, and this company who owns the system will ask for a certain set of features so they can reach a certain business goal, but the requirement gathering is incomplete if we don’t listen to the real users of the system who normally are customers of the company who owns the system.

If you have a great group of developers, QAs and BAs, all veterans in using Agile, Lean, Testing, DevOps and Continuous Delivery, all of that is useless if you are not able define what is the minimal set of features that can create value for the customer in the first release. And subsequently define the minimal features to be developed and deployed that brings greatest value to real users. The Lean Startup movement calls it MVP (Minimal Viable Product). Mark Denne and Jane Cleland-Huang, authors of Software by Numbers, first published in 2003, coined another term for this minimal set of features. They call it MMF (Minimal Marketable Feature).

The Agile Manifesto says that we should value “Customer collaboration over contract negotiation” and set as it’s first principle that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. The issue with these two statements is that it assumes that the customer who is the owner of the system knows what is “valuable software”. However, the customer normally knows what is “valuable software” for him, i.e., he knows what are his business goals that they want to achieve with the system. The problem is that the customer doesn’t know his own customers/users enough in order to define the requirements upon what a system should be developed, i.e., the customer doesn’t know what is “valuable software” for his own customers/users.

It is the Product Manager’s role to understand the users of a product/system, the problem the users have, and should bring this information back to the developers and experience designers so these three roles can jointly come up with a product/system that solves the users problem and, at the same time, meet the system owner’s business goals.

What do you think? Do you agree? Disagree? Share your comments below! 🙂

18 people like this post.

Agile Product Discovery in a Non-Startup Environment – Building MVPs
Nov 29th, 2011 by Joca

As mentioned in my first post about Agile Product Discovery, I’m trying to take the ideas I used in my lean startup experiment (phase 1, phase 2 and phase 3) in a non-startup environment.

Locaweb has almost 700 employees now. We ended 2010 with approximately $100M in revenue. We have around 130 people in our engineering group which include software developers, system administrators, user experience designers and product managers. We decided to use the SaaS team – around 25 people – as the group who will be part of the experiment.

In phase 1 we worked on figuring out what to do. The next phase is building the MVPs!

Organizing the team

From the 10 ideas we tested, 6 had enough traction to motivate us to build the MVPs, i.e., the minimal viable product. However, one of them was not simple enough to be developed as an MVP in 1 week so we decided to move on with 5 MVPs. The self-organized into 5 groups of 5 people each to work on developing the 5 MVPs. We wanted the groups to have focus during a whole week, so the groups were allowed to work in a different place so they ware not disturbed by daily work. Since we could not leave the company without anyone capable to deal with daily needs of our existing SaaS products, we decided to have 2 teams working during one week and the other 3 teams working during the next week.

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

The MVPs

And with no further ado, here are the MVPs:

Lessons learned

  • It was good to have the teams fully focused for a whole week.
  • Since we put in the same team people who are not used to work together, it was a bit difficult to estimate the effort and many times we under estimated the effort.
  • In some products we believe we didn’t get the M for minimal correctly. We may have built sub-minimal viable products that may require another week to get to the minimal level.
  • Back to the daily activities of the non-startup environment it’s a bit difficult put some energy, even a small amount, to the MVPs.

Next steps

Now we are measuring the interest in each of the MVPs. We intend to have another Agile Product Discovery week in Feb/2012. During this week we intend not only to discover new products, but also work on the existing MVPs, specially those that we believe are sub-minimal.

3 people like this post.

Agile Product Discovery in a Non-Startup Environment
Sep 15th, 2011 by Joca

I mentioned here about my lean startup Experiment (phase 1 and phase 2). I’ll post an update on this topic soon.

Here I want to share another experiment I’m running. I’m trying to take the ideas I used in my lean startup experiment in a non-startup environment.

Locaweb has almost 700 employees now. We ended 2010 with approximately $100M in revenue. We have around 130 people in our engineering group which include software developers, system administrators, user experience designers and product managers. We decided to use the SaaS team – around 25 people – as the group who will be part of the experiment.

I presented to the group my lean startup experiment and proposed that we experimented doing the same.

So we now have 4 phases for the Agile Product Discovery:

  • Phase 1: figure out what to do
  • Phase 2: specify the product
  • Phase 3: implement the product
  • Phase 4: monitor the product performance

We decided to break phase 1 into 3 steps domes in 3 different days in small chunks of 3 hours each. However, we realized that it would be more beneficial to work on the 3 steps in one full day instead of breaking it into 3 separate sessions in different days.

Phase 1 – Step 1 – Product Ideas

First phase of the experiment was to brainstorm product ideas. We used 2.5 hours for this phase. We divided the group into 5 groups of 5 people each and the groups have to come up with product ideas or feature ideas for existing products. The only constraints were that the idea should be targeted to SMBs, the target segment for Locaweb. Should not be targeted to niche groups such as lawyers or medical doctors. Should be possible to develop an MVP (Minimal Viable Product) in 2 days with no interruptions.

Each group come up with 10+ ideas so we were able to generate a total of 50+ ideas. Each group had to filter the ideas down to 5. Then each group presented the ideas to the rest of the team, who made questions and decided what ideas to move to phase 2. At the end of the session we decided not to included any features of existing products, only new products should go to the next phase. We end up with 13 products in our list!

Phase 1 – Step 2 – What Is The Problem?

For phase 2 we got more 3 hours. During 2.5 hours the 25 people self organized to define for each product what was the problem that the product was solving, for the problem will be solved and why it is worth to solve this problem.

From the 13 products that came out from phase 1, we dropped 4 and kept 9.

Phase 1 – Step 3 – Creating Pages and Ads

In step 3 we created the pages using unbounce and the campaigns with Google AdWords.

Final remarks about phase 1

This is it for phase 1 – figuring out what to do.

It’s a bit harder to do product discovery in a non-startup environment. Even if you have full support from senior management, it’s difficult to get away from day-to-day tasks. For this reason, as I mentioned earlier, I suggest doing the phase 1 in a full day and not divided into 3 steps in different days as we did.

Other than that, the creative process from idea generation to single page plus ad implementation was quite fun and engaging. The team was really energized. 🙂

In future posts I’ll comment on the results of phase 1 and the work done in phases 2 and 3. Stay tuned!

6 people like this post.

Management 3.0
Aug 28th, 2011 by Joca

I mentioned earlier that one of the sources I’ve been reading and enjoying is Jurgen Appelo’s posts about agile management. I’ve been reading his posts for a while, since the time he was the CTO of a dutch company. I really like the way he connects agile methodologies and complex adaptive systems theory.

I’ve mentioned his work in 4 posts:

Now he is 100% focused on his agile management coach career. He recently launched a book entitled “Management 3.0: Leading Agile Developers, Developing Agile Leaders“.

He also provides Agile Management courses.

Last week he was in São Paulo providing his management course at AdaptWorks and I had the opportunity to attend his course.

I’ll make a brief summary of the course below, as a way for me to review what we discussed during this two days. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.


After a quick introduction about the ideal size of a group and quick introductions of the attendees, Jurgen explained quickly about agile software development and then introduced Martie, the Management 3.0 representation with the 6 aspects of management that we should take care if we want to be good managers.



Then Jurgen explained briefly about the theory of complex systems and the types of fallacies we may fall into if we don’t use complex systems thinking when managing teams.

The seven fallacies

The seven fallacies

To end the introductory section, we did a group exercise where we analyzed some situations to identify what was the fallacy in play.

Energize people

When discussing about people, Jurgen talked about intrinsic and extrinsic motivation and presented us with the 10 intrinsic desires:

  • Acceptance The need for approval
  • Curiosity The need to think
  • Power The need for influence of will
  • Honor Being loyal to a group
  • Social Contact / Relatedness The need for friends
  • Idealism / Purpose The need for purpose
  • StatusThe need for social standing
  • Independence / Autonomy Being an individual
  • Order Or stable environments
  • Competence / Mastery The need to feel capable

Intrinsic desires

Intrinsic desires

Exercise time: we analyzed individually how we are in our current jobs in terms of each of these 10 intrinsic desires.

Then Jurgen presented some tools to helps us know what is important for the people in our team:

B = f (P, E)

B = f (P, E)

Group exercise: we had to use the practices below to get to know 10 important facts about Ellen, a member of a fictional team managed by us.

Empower teams

Here Jurgen presented the 7 delegation levels I already mentioned in a previous post.

Delegation levels

Delegation levels

Group exercise: delegation poker where we were presented with different situations where we needed to figure out the appropriate delegation level.

Align constraints

A leader must:

  • define the constraints (playing field, players), but let the system create its own rules.
  • protect people against bad team formation
  • protect good teams against non-team players
  • protect shared resources (energy, budget, environment, office space, food, sysadmins)

The 4 I’s to cope with the Tragedy of the Commons:

  • Institutions: create trust to accept common rules
  • Information: increase understanding of situation
  • Identity: increase social belonging across teams
  • Incentives: address behaviors with small rewards

3 kinds of purpose (or goal) for a team:

  • Intrinsic purpose: an easily spottable trend in a team, e.g., produce software.
  • Extrinsic purpose: assigned by caretaker, e.g., make money.
  • Emergent purpose: chosen by the team, e.g., be a winning team.

Qualities of a good goal

Qualities of a good goal

Exercise time: we had to define a purpose for the course.

Develop competence

First Jurgen described how we can improve.

Competency development

Competency development

Then he described how we can measure our improvement.

KPI matrix

KPI matrix

Exercise time: we had to define KPIs according to the matrix above to our organization.

Grow structure

We can have two types of team organization, functional or cross-functional, it depends on how often team members need to communicate. Product managers, user experience designers and software developers need to communicate all the time about the project or product they are working on, so they need to sit together in a cross functional team. HR people on the other hand need to talk constantly to other HR people so they need to sit in a functional HR team.

Jurgen also advised we should hire generalizing specialists, promote informal leadership and widen job titles.

Exercise time: Meddlers.



Improve everything

How can I…

  • Make the rest of the organization more Agile?
  • Motivate my employees to develop themselves?
  • Convince customers they should accept Scrum?
  • Etc…

In order to change things we need to consider:

The system

  • Plan: What Is Your Goal?
  • Plan: Where Is It Going Well?
  • Do: What Are the Crucial Steps?
  • Do: When and Where Do You Start?
  • Check: How Do You Measure Results?
  • Check: How Do You Get Feedback?
  • Act: How Do You Accellerate Results?

The individuals

  • Awareness: How Will You Communicate?
  • Awareness: How Will You Set an Example?
  • Desire: How Do You Make It Urgent?
  • Desire: How Do You Make It Desirable?
  • Knowledge: What Will You Tell Them?
  • Knowledge: Who Will Be Teaching?
  • Ability: What Makes It Easy?
  • Ability: How Can They Practice?
  • Reinforcement: What Are the Short-Term Wins?
  • Reinforcement: What Makes It Sustainable?

The interactions

  • Initiators: Are You Committed?
  • Initiators: Who Is Assisting You?
  • Innovators: Who Will Be the Innovators?
  • Early Adopters: Who Are the Early Adopters?
  • Early Adopters: How Will the Leaders Help?
  • Early Majority: How Do You Reach the Early Majority?
  • Early Majority: How Will You Cross the Chasm?
  • Late Majority: How Will You Deal with Skeptics?
  • Laggards: How Do You Prevent a Relapse?
  • Laggards: How Do You Deal with Resistance?

The environment

  • Information: How Do You Make Things Visible?
  • Information: How Do You Ease Communication?
  • Identity: What Is the Group Identity?
  • Identity: How Can You Apply Peer Pressure?
  • Incentives: Can You Incentivize Good Behavior?
  • Infrastructure: Which Barriers Will You Remove?
  • Infrastructure: Which Guides Will You Place?
  • Institutions: Who Can Make the Rules?

Culture changes only after you have successfully altered people’s actions, after the new behavior produces some group benefit for a period of time.

John P. Kotter, Leading Change

Exercise time: each member of the group tell one story with she needs ideas on how to change, then the group select from the list above and discuss.


This is just a brief summary of the 2-day course, as a way for me to review what we discussed during. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.

12 people like this post.

Agile Product Discovery
Aug 21st, 2011 by Joca

I recently posted and twitted about my lean startup experiments.

The word startup in lean startup may be misleading because startup gives the idea of a new company creation. However, the concept on lean startup fits very well within established companies, no matter its size. I believe that instead of using the startup word, I’d rather name it as Agile Product Discovery, an iterative process of discovery of a problem and its best solution that can be turned into a product.

I’m reading now The Entrepreneur’s Guide to Customer Development: A cheat sheet to The Four Steps to the Epiphany:

The book’s cover is a cheat sheet by itself:

Here’s an excerpt of the book to give you motivation to read it all:

First, draw a map of your ecosystem.

  • The entities involved. Draw a box or a circle representing each entity in your ecosystem. Entities include users, customers, channel partners, technical partners, strategic partners, advertisers, your customers’ customers, etc. Include all entities that either provide value to you or receive value from your product. Value can be derived from money or the use of a product. Value can be direct (what a user receives from using a product) or indirect (money an advertiser gets from product user eventually).
  • Flow of currency. Draw lines or otherwise show your assumptions regarding the flow of currency. Who pays whom?
  • Product Distribution. Show your assumptions regarding how the product moves through channel(s) to reach end users.

Questions to consider:

  • Are you relying on third party technology that requires a formal partnership?
  • Are you relying on channel partners that will help you bring the product to end-users?
  • If you have a “free” business model and are looking to scale users, who will you eventually earn money from?
  • Are you partnering with a manufacturing firm?
  • Will you sell data or leads to third parties?
  • Does your product benefit your customers’ customers?

Second, define the value proposition for each player.
Each entity is only a member of the “ecosystem” if it will receive benefits by participating. For each member of the ecosystem, what benefit do they gain and what are they willing to trade in exchange? These value proposition statements will evolve into your core C-P-S (Customer-Problem-Solution) hypotheses that you test during Customer Discovery. For now, however, provide a concise description of the value you presume they will receive.


  • Users will be entertained
  • Advertisers get the attention of thousands of users
  • Buying influencer is happy to choose “green technology”
  • Customer’s customer gets highly qualified leads
  • Channel able to sell services on top of product
  • Customer will save money, mitigate risk, or increase market share

Third, posit a final MVP
As defined above, an MVP is “a product with the fewest number of features needed to achieve a specific objective, for which users are willing to ‘pay’ in some form of a scarce resource.” The reason the definition is somewhat obtuse is that we wish to differentiate between a “final” MVP and one or more intermediate MVPs. Final MVPs ostensibly test the business model. Intermediate MVPs test high risk components of the business model.

To develop assumptions regarding your final MVP, think of what you need to provide to each entity with whom you have a direct relationship in order to achieve the value you identified above. What are the basic features of the product each user requires to get the ecosystem functioning? What does each entity pay – whether money, attention, resources or some other currency? Describing what your final MVP looks like establishes an end point to the Customer Discovery process.

  • Currency = what the user/buyer “pays” for using the MVP
  • MVP Metric = what you are measuring to determine viability
  • Value Determinants = what the user/buyer requires (minimally) in order to spend their currency, such as features

Fourth, where’s the risk?
The goal for laying out a path for your Customer Development efforts is to prioritize and test your gating factors. If you validate key assumptions, you have proven critically important aspects of your business model. If you hit unexpected roadblocks and points of failure, then you have increased your odds of success by catching these issues early.

Think of critical near-term risks. Does your technology represent a significant risk? In other words, can you build what you believe the market needs? If your technology is difficult or costly to produce, what market-testable milestones can you build that would result in sufficient evidence to induce you to pivot or move forward? A proof of concept? A prototype? A demo?

If your risks are predominately marketing ones, what minimum set of features will result in paying customers? Or: What minimum set of features will result in a minimum of X number of users?

Time and money risks may affect intermediate MVP decisions. If your MVP will require $XM to build, but you only have $X/1000M, an intermediate MVP might be the answer to “what must I prove in order to acquire additional funding?”

Think of dependencies. If your final MVP requires that X happen, then can you build an intermediate MVP around X? What does X depend on? If possible, go to the root of the dependencies.

Fifth, create your Value Path
Your value path is the journey of Customer Discovery that takes you from where you are today to your proposed final MVP and includes both intermediate MVPs and core assumptions to be tested. From the risk table you created, map out the set of core assumptions you need to test for each identified gating factor. For each intermediate MVP, you will likely have a set of assumptions to test through direct customer interaction, in addition to a version of the product to build and test through usage.

1 person likes this post.

Try AND instead of OR
Jul 20th, 2011 by Joca

I recently read the post “And” Leadership written by Jim Highsmith that caught my attention on using AND instead of OR:

One of the traits I think is very important [for an agile leader or manager] is that of “And” rather than “Or” leadership. The most pressing issues to face leaders are usually paradoxical; they appear to have contradictory solutions. Take for example the paradox of needing predictable delivery with that of needing to be flexible and adapt over the life of a project.

It’s easy to be an “or” leader. Pick a side and state your case loudly, over and over until the opposition gives up. It’s much more difficult to be an “and” leader, balancing between seemingly opposite strategies. However, in our ever-changing and turbulent world, slavishly following the “one right answer” is a recipe for disaster.

It’s interesting that in many situations in agile development we face situations where we initially think it’s an OR situation but when we analyze it, we realize it’s actually an AND situation where we need to balance apparently opposing concepts:

  • freedom and responsibility
  • cross-functionality and specialization
  • continuous learning and iteration pressure

It’s interesting that this applies not only to agile development but to many aspects of our life. Should I be more concerned about my family or my job? Should I give more attention to my kids or my companion? Experiment changing or by and. 🙂

Lessons learned

Next time you face a situation with opposing concepts, instead of choosing the easy path of taking sides and being an OR person, try to figure out a way to be an AND person. It will be much more difficult to ben an AND person. Sometimes it won’t even be possible to use AND in certain situations, but just trying to figure out if it is possible will be a good exercise with interesting outcomes.

1 person likes this post.

The agile company
May 27th, 2011 by Joca

What does it mean to be agile?

Being agile means being able to respond adequately to changes.

Why is it important to respond adequately to changes?

Because the environment we live in changes all time and it has been changing faster over the years. If we don’t respond adequately to those changes we may end up doing things inadequately, i.e., things that won’t get us to our objectives.

Agile software development

The agile software development provides some suggestions on how to respond adequately to changes in a software development project. The main idea is to deliver software frequently so we get feedback on what is being delivered and adapt accordingly. In agile software management, adequate response to changes are possible due to:

  1. frequent delivery of value to customers
  2. feedback on what is being delivered
  3. adapting accordingly

As a consequence, from agile software development derived:

  • continuous delivery which means the frequent delivery of software in production so we can have feedback as early as possible.
  • feature teams which means collocating on the same team everybody needed to develop and deliver the system, including software developers, QAs, BAs, product managers, sysadmins, interface developers, interface designers, interactions designers, customer support, etc.
  • agile product management practices which come in many different flavors, including product discovery, customer discovery, customer development, inception, sprint 0, business model generation, etc. I’ll probably write a separate post on this topic.

However, all of this seems to be limited to the IT world, more specifically to the software design, development and operations groups. The problem with this limitation is that even though those groups are agile, i.e., are able to respond adequately to changes, the rest of the company may not be as able as those groups.

Different cycles in different groups

On a company level we normally have big annual – or even multi-annual – cycles of planning and forecasting. Those cycles are normally very painful. Jim Highsmith wrote an interesting post on the many cycles companies pass through and how they tend to be not synchronized. At the end of the article, Jim suggests that:

When companies get serious about Enterprise Agility, one area that will require major change is moving from financial cycles being the driver to focus on a product-driven (deliverables) “Short-horizon” model (that does deliver the required financial information but is not driven by that financial cycles) that is more adaptable to changing conditions.

Another suggestion for companies interested in Enterprise Agility is moving the planning and forecast process to a more agile fashion such as the “rolling forecasts”. The idea is quite simple. Instead of going through the budget process every year and make it a huge yearly event, we should review and adjust our budget every month or quarter, continuously planning and budgeting “the next 12-18 months to reflect real time changes in planning assumptions, both outside (competition and economy) and inside the company. Rolling forecasts make the budget process more agile, relevant, and useful. Rolling forecasts get managers more focused on the future and less on the past. The more practice people have with forecasting and planning the better they become.”

Agile means continuous improvement

Being able to respond adequately to changes means that we need to continuously improve the way we do things based on the feedback we gather. Even though the Agile Manifesto is 10 years old, the agile ideas has been around for longer than that. The idea of continuous improvement is part of the basis of the Lean Manufacturing System, which has been around since mid 1980s. In the early 1990s the term Agile Manufacturing was formulated as “a term applied to an organization that has created the processes, tools, and training to enable it to respond quickly to customer needs and market changes while still controlling costs and quality”.

So the ability to respond adequately to changes in customer needs or market environment came originally from the manufacturing world.

The agile company

Peter Weill, director of the Center for Information Systems Research at the Massachusetts Institute of Technology (MIT), presented “The Agile Paradox” during the MIT CIO Summit in June, 2006. This presentation was based on a survey done by Weill and his team with a group of 649 companies and it brings quite interesting facts. Slide 4 shows the that agile companies perceive a 37% increase in their profit growth while staid companies perceive a 13% decrease.

Is your firm agile or staid?

Is your firm agile or staid?

The Economist Intelligence Unit made a report sponsored by EMC in 2009 called “Organizational agility: How business can survive and thrive in turbulent times“. The report is based on a survey with 349 executives around the world on the benefits, challenges and risks associated with creating a more agile organization.

The major findings are:

  • Organizational agility is a core differentiator in today’s rapidly changing business environment. Nearly 90% of executives surveyed by the Economist Intelligence Unit believe that organisational agility is critical for business success.
  • Yet most companies admit they are not flexible enough to compete successfully. More than one-quarter (27%) of respondents say that their organisation is at a competitive disadvantage because it is not agile enough to anticipate fundamental marketplace shifts.
  • Internal barriers stall agile change efforts. More than 80% of survey respondents have undertaken one or more change initiatives to improve agility over the past three years, yet 34% say they have failed to deliver the desired benefits. The main obstacles to improved business responsiveness are:
    • slow decision-making,
    • conflicting departmental goals and priorities,
    • risk-averse cultures and
    • silo-based information.
  • Technology can play an important supporting role in enabling organisations to become more agile. Technology should function as a change agent in the use and adoption of best-in-class knowledge- sharing processes, so companies can improve their use of critical data.

Also in this report there’s a quote from Weill where he explains why agility is importantant: “When I was a kid, the most successful companies were monopolies or duopolies, but in today’s globalised, free-market environment, the ability to satisfy customer expectations is core to profitability. If you’re not agile, you can’t do it, because customer expectations are never static.”

Wrapping up

So maybe it’s time to think not only in terms of agile software development or agile manufacturing but in terms of agile company, a company able to respond adequately to changes in customer needs as well as changes in the market. This will be achieved if the company:

  1. frequently delivers value to customers, employees and shareholders.
  2. proactively gathers frequent feedback on what is being delivered and reviews this feedback.
  3. adapts accordingly and improves how it delivers value.

It is a continuous improvement cycle, so it’s never too late to start! 🙂

If you liked this article, you may also like Agile Methodologies Are Processes, Agile Is Culture

17 people like this post.

Story map is a great tool for agile product management
Mar 30th, 2011 by Joca

Jeff Patton, who defines himself as agile old-timer, UX practitioner, good product evangelist and family guy, presented in his blog the concept of story maps, a replacement for backlogs that helps people see the forest and not only the trees.

The basic idea is that in order to understand your system you need to break it down to user activities. Jeff gives the example of an email system:

If I was building an email system (which I’d never be foolish enough to do) I might have an activity called: “managing email”, and “configuring email servers”, and “setting up out of office responses.”

Then you break those user activities in user tasks:

That story [managing email] breaks down into other stories like “send message,” “read message,” “delete message,” “mark message as spam” – stuff like that. I call these user tasks.

A story map may look something like this:

Story map diagram

Story map diagram

Story maps were brought to Locaweb by Alexandre Freire. We’ve been using it for months and we can testify it is quite helpful! You should give it a try! 🙂

Some photos of our story maps:

Story map

Story map

Story map

Story map

Story map

Story map

2 people like this post.

Agile management
Mar 4th, 2011 by Joca

When we implemented agile methodologies at Locaweb, the same way that some developers asked to leave because they were not willing to adapt to some of the agile principles that we decided to embrace, some of the existing managers also didn’t adapted well to the changes in their roles and responsibilities and asked to leave.

At the time, I discussed this topic with people from other companies and they mentioned that it’s not unusual to have developers and managers leaving the company when moving to agile. I remember even someone mentioning that in average 10% of developers leave. That was back in 2007 / 2008. I’m not sure if this tendency have lowered lately, since agile is becoming more and more mainstream.

I also read – and continue to read – a lot about the topic. One of the sources I’ve been reading and enjoying is Jurgen Appelo’s posts about agile management. I’ve been reading his posts for a while, since the time he was the CTO of a dutch company. I really like the way he connects agile methodologies and complex adaptive systems theory.

Now he is 100% focused on his agile management coach career. He recently launched a book entitled “Management 3.0: Leading Agile Developers, Developing Agile Leaders“.

He also provides Agile Management courses that seem to be quite interesting:

Checkout also his presentations on slideshare. Checkout this presentation on authority and delegation:

Other posts about the same topic:

1 person likes this post.

Interesting stuff
Feb 28th, 2011 by Joca

1 person likes this post.

»  Substance: WordPress   »  Style: Ahren Ahimsa