Value Stream Mapping a tool to help Systems Thinking
Hi guys, in this post I want to share with you a nice story that happened several months ago with one of my teams. At that time I had a team that was making the first steps towards Agile. They were a fantastic team, really eager to learn but still with the “old waterfall” mentality. They had a typical approach where the developers did development work and the testers – testing, not really a truly Agile team. I believe this is a common problem for teams that are switching to Agile: seeing only a small picture, they are not able to see the entire system. I believe they lacked “System Thinking”. But what is “System Thinking”?
Shortly explained, “System Thinking” is the ability to see the “big picture” and not to be focused on just a small part of your job. For a better explanation, I will use as an example my former team to demonstrate my ideas. In that particular team the work was arranged so that the developers had a set of User stories to work on. A finished User story was passed over to the testers for testing. The problem was that although for the developers these stories were quite simple to implement, they were quite challenging for testing because of several compatibility issues that required full allocation of testing resources. When developers ran out of User stories they were asking the Product Owner for more stories to work on. However, the PO acted rationally and did not give them any new stories until the team delivered everything to the iteration backlog. It was obvious that the team needed some help to visualize everything that was happening. How to help the team?
Clearly, the developers had their best intentions in mind: they ran out of work, therefore, they asked for more tasks. However, because of their lack of “System Thinking” they did not understand that more work for them would mean more pressure on the testing resources that were already fully allocated and, ultimately, an outcome of a poorer quality of the team effort. Apparently, the developers needed to understand that it was not anymore a matter of “us and them” because their job is accomplished when a customer gets the product, and the product would be ready when the team would act as a single unit. I have discussed this issue with some of my colleagues and they gave me a good idea: in next iteration to use Value Stream Mapping (VSM) for observing how the system behaved. This tool is a great instrument to identify different aspects of a system. If you want to use it you need to take some time to explain this tool to your team. From my experience not many people apply this in software development. VSM can be a fantastic tool to be used at retrospectives, but this could be explained in another post ;). Let´s see what happened at the iteration retrospective (an iteration where VSM was used).
By that time, the team was already familiar with the VSM and they were quite impressed with the amount of information we collected using it. Having looked at different VSMs (we created one for each different User story), it was not long before the team could see that bringing more User stories to the iteration would not translate into higher output because the testers were already fully loaded, therefore, producing more code would only mean that the testers would not be able to deliver everything on time. The team started appreciating more “System Thinking” and not just think anymore in terms of their separate “boxes”. After some discussions, the developers decided that in the folllowing iteration they would help the testers with all the testing activities to deliver more User stories as a team. In the following iteration the developers and the testers worked more as a team and the output of the joint effort of the team was indeed of a higher quality and volume.
Do you think this is something to consider when you work with your teams? What are your ideas on the topic?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
What metrics should we use in an Agile project?
Hi guys, this week I started to read a book that is part of a reading list for the CSP exam. “Extreme Programming - Installed” and I found an interesting chapter about a topic that me and my colleagues were struggling with couple of weeks ago - “What metrics should we use in order to see how the project is progressing? ” Let´s take a look into it…
Ron Jeffries, Ann Anderson and Chet Hendrickson said there are mainly six kinds of metrics that is useful to play attention to in our projects: Resources, Scope, Quality, Time, Tracking and Reporting Scope, Tracking and Reporting Quality. So let´s take a look at each of these metrics.
Resources
Authors of the book defend that we should always keep a track on key resources - planned versus actual. These are number of developers, testers, customers assigned to a project and number of computers in a development, test and production.
Scope
Number of stories over time: how many stories exist, and how many of these are actually accomplished. We can also see how many stories were initially planned vs stories that we have on the backlog at the moment. This metric can give us an idea whether a product owner adds lot of stories or whether he sticks to the initial release scope.
Quality
Here, a simple graphic can be used to show how many automated test cases were run and how many of these were successful.
Time
The core is to track the results of each released plan and discuss the outcome and impact on the project when any functionality was added or removed.
Tracking and Reporting Scope
There are two main metrics: Iteration and Release burndown. The iteration burndown chart helps a team to track the iteration work (estimated vs done).
To track how the release is progressing we can use a graphic presented below. The red bar shows the stories that need to be implemented, green bar demonstrates the ones that were already achieved and the yellow ones the stories that were added to the product backlog.
This website serves as a source to a picture displayed above blog You can find more information how to “Read a Release Burndown Chart”.
Tracking and Report Quality
This part describes three interesting metrics. According to the authors, the first metric, that demonstrates the percentage of unit test that passed on an iteration rate, should be available. The number of successful tests tell how well a team is doing. Please, do not take me wrong, this does not mean that teams should not care about having all tests green during the iteration. You should always aim to have it as “green” as possible, but tracking it on iteration level is a good way to see how the team is doing on a release basis. Here you can find more background information to support this statement.
The second metric applies the same thought as mentioned above. However, this time it serves for acceptance and integration tests. Perhaps, in this case, it makes sense to separate the test by product area in order to see which of the product areas are more complicated. Below you can find a report for acceptance testing during an iteration.
Finally, as a last metric, a comparison matrix - test cases vs date can be used. This would show us which test cases failed and when did it happen. This would allow us to identify any trend that could emerge from there.
Do you think there is anything missing? Please feel free to comment.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Is there any demand for “Agile Localization”?
Hi guys, this week I want to tell you what I have been up to for the past couple of weeks. I have written about it as it is always easier to see new ideas in a better light once they are written down. The purpose of this particular post is to invite you to a discussion about Agile Localization.
I have previously mentioned that I started with Agile some years ago, around 2007. Few years onwards while working for one of my previous employers I became responsible for improving the localization process for several products. At the time the localization for those products was done the traditional way - at the end of the product development process towards the end of the project. My role here was to change the traditional approach in-line with the Agile approach so that the product deliverables of each iteration would be localized. The initiative was a success and we were able to have product deliverables of each iteration localized in 87 different languages. After some years of working with Agile I decided to share all the knowledge I acquired during those years with other Agile developers out there, so I started the “Agile Localization” project.
I started writing a book on the subject thinking that it would be something I do in my spare time, but feedback I received from several friends and colleagues made me believe that my interest in Agile localization could lead to something more than just a book. Such as, a consultant might consider writing a book in order to have a successful career in consultancy. Together with two other colleagues we started a consulting company “Oikosofy”. The website mentions several innovation and Agile services that we offer, but there isn’t a mention of Agile localization there.
However, I think Oikosofy could offer Agile localization as a service to localization vendors to be offered to their customers. At least this is what I had in mind when I had a “sales call” from one of the vendors. But it seems the guy did not understand me, rather, as one of my business partners puts it: the problem is not with the listener but with the messenger. I believe, I did not explain myself well enough. So, I take this opportunity to explain my idea in order to see how you like it. Let’s say in this post I present my MVP(Minimal Viable Product) and I would like your opinion on whether there is a demand for this service out there.
The idea behind this service is to help companies sync their localization with their Agile development, so that the deliverables for each iteration would be localized. Of course, to make this possible a team must be already working in Agile and if they are not working in Agile yet, they can always contact us for help with the transition to Agile :). But coming back to the topic, this would be a service designed for teams that are working already in Agile yet still treat localization as something to be done outside the Agile process, at the end of the entire product development process. So our role would be to coach the team while working together with them and helping them adopt Agile localization practices so that they could have their product deliverables localised for each iteration.
This service would be offered as a partnership with the localization vendors who would take care of the localization of the product and we would be working together with the customer changing their way of doing localization. This would help the localization vendors because it would improve their collaboration with the customers taking it to a new level. Instead of receiving a huge amount of strings at the end of a development project they would be able to deliver small batches of translated strings for each iteration. This would be also beneficial for the customer because it would allow the customer to have the deliverables of each iteration in all the languages they require. Another advantage here is that the feedback loop would be scaled down, too, which means the customer together with the localization vendor can timely fix any problems with the localization thus improving the quality of the product and reducing its time to market.
So this would be one of the Oikosofy services in a nutshell - Agile Localization :). This is my idea of how Agile localisation could be developed into a service and I would greatly appreciate your feedback. Do you think there is a need for such service? Do you think Localization deserves to be a special service for Agile development, what would be pros and cons of it?
Thank you so much for your most valuable input that will help us a lot in developing further the Agile community!
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
How to help a team that is not performing so well - Part III
In my last post I discussed the pyramid with the five dysfunctions of a team and the appreciation exercise. If you did not see my previous posts, I would highly recommend you to have a look at them first, because this is the last post of a series of posts where I present a possible structure of exercises to help a team recover from a non-productive situation. Here I will explain the remaining exercises necessary to finalize the set of my Team Recover Exercises.
The following exercise is about reinforcing the Scrum values. Lyssa Adkins uses the metaphor of a tree, stating that in order for a team to be highly productive, they need to have strong roots. When the roots are strong and solid the tree can grow and flourish bearing beautiful fruits. Below you can see Lyssa’s example.
[youtube=http://www.youtube.com/watch?v=t3kKechcwYM]
Commitment is the state or quality of being dedicated to a cause, activity, etc.. A commitment should never be broken and if it is broken it was not a commitment but an empty promise and a lie. In the Scrum world this means that everyone involved in developing a product is committed to working towards a common objective.
Courage is the ability to confront a fear, pain, a danger, an uncertainty, or intimidation. In software development all these feelings will be always present and it is up to the team members to try to dispel anything that prevents them from being successful.
Openness is the ability to be open to new ideas, new approaches and new ways of working. This is a fundamental state in Agile software development because every day teams encounter different problems that need to be approached differently, being open is mandatory for achieving success.
Focus is the process of selectively concentrating on one aspect of the environment while ignoring other things. In software development this means teams should completely concentrate on one topic at a time, they should not start a new topic before finishing the previous one.
Respect is a feeling of deep admiration for someone or something elicited by their abilities, qualities, or achievements. In Scrum all team members interact closely, respect is mandatory for such relationship to work.
In this blog, you can find another point of view about Scrum values. I believe one hour should be enough to refresh the Scrum values with the team. After this exercise they will be ready for a more practical approach.
At this point, with the values written on a flip-chart, the team is ready for a new exercise. Make sure to reserve half of a day for the next exercise. By now you will need a tool to help the team recap the basics of Scrum and I believe the Lego Scrum is highly effective for that. The goal of the game is to simulate every aspect of the Scrum process: the team members will be asked to build an entire city using Lego blocks. The team will have to put in practice everything learned previously. More details about the Lego Scrum can be found here.
After all these exercises I believe the team will be ready to start all over again and start working better as a team delivering software products of higher quality.
I am not expecting to find a super productive team upon arriving to the office right on the next day after the exercises :) This is only a starting point, like I mentioned in my SECOND post, there can be five dysfunctions in a team and the exercises that I proposed are just for tackling the most fundamental problems, such as lack of trust. It is up to the Scrum Master or Agile Coach to continue working with the team in order to help them to overcome problems and to become highly productive as a team.
Hope you’ve enjoyed this series of exercises. If you want to try it in your own team, I would like to ask you for a favour: please, come back and share the results :).
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
How to help a team that is not performing so well - Part II
In my previous post I talked about how to create a common goal for your team and I mentioned a book that I read some weeks ago(The five dysfunctions of a team). This book discusses why even most successful teams struggle to get good results. By following the link below you can find the pyramid of dysfunctions discussed in the book.
Presenting this pyramid to the team could be the second exercise. Based on my experience, most of the team members will identify at least one problem from the pyramid. Visualizing this will make them think a bit about the status quo situation while realizing that much is required to be done in order to have a great team. I think one hour should be enough to familiarise the team with the pyramid and to answer all their questions.
Since the base of the pyramid forms Absence of Trust, I will focus on an exercise for improving this specific aspect. My team tried this exercise some weeks ago. Clearly, we had problems in the team and lack of trust was one of them. To improve the situation, the facilitator of the meeting came up with an exercise for the team: “The Appreciation Exercise”. The point of the exercise is in answering the five questions presented in the following picture:
Importantly, in order to answer the fourth question the team should express their request as a wish. This was an awesome opportunity to use NVC. Although seemingly a really simple exercise, it makes a difference: the participants will connect with the feelings, emotions and wishes. But make sure you reserve half a day for this exercise, you would want to spend a good amount of time on it.
It is too early to say if the exercise really worked, but one thing is for sure - the spirit of the team after the exercise was quite high and all of us were really pleased with the outcome. I am sure that everyone left the room eager to improve the existing situation. It is important to realize that it takes time to see the results of this exercise, because these issues cannot be solved in a day or two, but they are certainly useful for bringing the team together.
After the “Appreciation exercise” it might be the right time to refresh the Agile/Scrum values, but this is a topic for my next post.
Thank you and see you in my next post,
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
How to help a team that is not performing so well - Part I
Hi guys, I am sure that most of you at some point have had performance issues in your teams as well as team spirit issues. This post will be part of a series of posts where I want to talk about how to help a team to get back on track. For this series I will have a development team (Scrum Team) in mind, but this idea can be applied to any dysfunctional team. The ideas used in this post came from different sources: my own experience and the experience of my team, as well as from a course given by Lyssa Adkins and Michael Spayd that I took some weeks ago.
An important aspect that Lyssa and Michael emphasized at the course was that when you have a problem caused by the poor implementation of Agile you should address it directly, the Agile values should be reaffirmed and the system should be revealed to himself.
The problems should be addressed “directly”: you should state the problem as you see it and then ask the team what they want to do about it. “Reaffirmation of Agile” means you should retrain some of the Agile values or principles that are not present anymore. “Showing the system to himself” means showing the system to the people involved through observation of what is going on, one good exercise to achieve this can be found HERE.
I wanted to give you some background information because I believe that it will be extremely difficult to tackle a problem using any kind of activity if your team does not see that problem and, most importantly, if they are not interested in solving it. With the assumption that people will try to solve the issues, I present below activities that can be seen as a possible way to restore the energy and good practices in the team. These exercises can be used in a two-day team building exercise.
In my humble opinion, the first thing that we must ensure in order to have a successful team is to establish a common goal for all members of the team. In my case I am talking about a development team, so I believe the common goal is to deliver a high quality product to the customer. In this situation the Product Owner has a key role as the master of the product vision and the responsible for sharing that vision as well as for making sure that everyone understands what product should be built. I am going a bit further by saying that the Product Owner is the ultimate responsible for creating the common goal for the team.
A possible exercise would be to ask the Product Owner to prepare a press release and then to present it to the team. With this exercise the team will be able to see the big picture and understand WHY they should work in a team and WHAT they need to accomplish as a team. In my opinion, this exercise is important for two reasons, on the one hand, if everyone in the team knows what they need to do the exercise is reaffirming the common goal, while on the other, if the team members do not have a clear idea what their common goal is, having this exercise will help them to create the necessary common goal. The exercise should take 2 hours, which should be enough for the Product Owner to explain the vision and to answer any possible questions.
Hopefully, with the above exercise the team will have a common goal and can move towards the next step. Some weeks ago I read a book called The five dysfunctions of a team . The second exercise is based on this book, but this is something that I will explain in my next post.
Hope to see you soon in my next blog,
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Constellation - A Good Exercise to “Set the Stage” At Your Retrospectives
Hi guys, this week I offer you a small exercise that can be used at your retrospectives, specifically, in the “Set the stage” part. There are many different exercises out there that can be used to start a retrospective, but I particularly like this one. I learned it a few months ago in Lyssa Adkin’s workshop in Stockholm (Agile Coaching Teams).This is a great exercise for people who do not like or do not feel comfortable sharing openly their opinion/feelings, at least in the beginning of the project when they still do not completely trust everyone.
We begin a retrospective with a welcome to the team members and with setting an affirmative goal for the session and this is where the “Constellation” exercise can be used. Like I have already said, due to the cultural backgrounds or the personality of team members, answering some questions can be difficult for some, but this exercise can help, because people do not need to speak in order to answer questions. He-he, now you might start wondering, “How could it be possible to answer questions in a team meeting without speaking”? Here is how we can do that…
Start with making an open space, move tables and chairs around, if needed. Put an object on the floor and explain to the team that this object is the center of the Universe and kindly ask them to form a circle around it. Explain to them that you will read some statements, and while you are reading the statements you would like them to move closer to or farther away from the “Universe” depending on how true the statement is in regards to them. So, if they really agree with the statement they should move as close as possible to the “center of the Universe”; if they do not agree with the statement, they should step back away from the center. Once you read a question, let the team observe the “system”, as Lyssa said, “Let the system reveal itself”.
You can use any topic you wish for this exercise, e.g., “How mature is our continuous integration process?”, “How mature is our automated testing process?”, etc. Just choose a topic and ask several questions related to that topic and let them see where they stand. Like I said, they do not need to give verbal answers at all, they answer with the movements by showing their position in the “system”. You could do several questions until you feel a good vibe from the team. To benefit fully from this exercise, you could ask the team in the end: “Where were you surprised with the shape?” and let them talk to each other a bit.
As a next step, you can, for example, ask the guys to form small groups of no more than three people each and ask each group to write down what they think would be the most important issue to improve. Of these issues you could then routinely select the most urgent issues to be improved in the next iteration. After that just agree with the team who will be responsible for what and close the retrospective.
So what do you think about this? It was useful? Leave me your comments.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
How large stories can impact learning
Hi guys, this week I got inspiration for the post from a conversation that I had with one of my colleagues. I was explaining him the book that I read during my holidays - “Drive“. We went through many topics, but the one we discussed most was about Casual Friday, let me explain what it is.
In case you are not familiar with the term, you can think of it as a relaxed work day, the day when people are already in anticipation of the forthcoming weekend :). In the context of our discussion this pertained to that specific time that Google made popular with its employees: when they can use their time to do whatever they want, of course, within the company activities, but not necessarily related to their on-going projects.
The conversation continued for some time when he suddenly said that he cannot really do that, he does not have time to try this Casual Friday. He then explained that each their iteration takes two weeks, so if he starts using a day per week off the project they will have only eight days left and then they cannot deliver much for that iteration. At first, I could not understand him, so I decided to dig into it…
I asked him, “How come you cannot deliver anything in eight days? How long do you take to finish a story?” However, when he told me that each story usually takes six to seven days, I understood their problem. Of course, if they take seven days to deliver a story and if something happens, say a small delay, it would easily take them the whole iteration to deliver that one story, but they will not have any time for Casual Fridays.
In my humble opinion, they are just accepting too large stories. It would make sense for them to break these large stories into smaller units so that they could have more deliverables at the end of the iteration. Then I suggested that he tries an experiment: they could start creating smaller stories, say two-day stories, and they could see how many stories they would accomplish within the iteration. If everything goes well, they could deliver up to four stories per iteration and still have their Casual Friday.
I cannot promise that this would immediately solve their problems and allow them to have their Casual Friday, but I think they might be one step closer to it, because I truly believe that smaller stories are much better than the large ones.
This was just one example that demonstrated how large stories can have a negative impact on the development work. Here you can find more examples that explain why smaller stories are better for your development process.
What is your opinion about it?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Goals trap!!! Be careful when your boss establish performance goals…
Hi guys, 2013 is here now, so first of all, I would like to take this opportunity to wish you all a successful New Year! I hope you had a relaxing time with your families and friends. During my Christmas holidays I read a great book - “Drive”. It made me think about what really motivates us. Part of the book talks about goal setting, which I think is a perfect topic for my first post in 2013. As it is the beginning of the year, I am pretty sure that soon most of us will have this “popular” meeting with the management to define our goals for the next six months. But is this really a good thing? Let’s dig a bit more into it…
How many of you heard that goals must be SMART? Do you actually think it is a good definition for goals? SMART stands for Specific, Measurable, Achievable, Realistic and Time-scaled. An example of a Specific goal for a company could be increasing the market share, as compared to a rather general goal of becoming more profitable. In order to see if an objective was achieved, we must make it Measurable by attaching a number to it, for example, to increase the market share by 3%. Objectives must be Achievable, which means that the company capabilities and the market environment should allow them to come true. Realistic means that objectives must be within the company’s reach, to expect an employee to become next Freddy Mercury might be a bit too ambitious :). The last one, Time-scaled, means that an objective must be attached to a time-frame, for example, in 12 months you will sit down with your boss again and see if you reached your targets. Are you familiar with this definition? Do you agree with this approach? Let’s see what some studies proved regarding this topic.
According to the studies discussed in the “Drive”, goals tend to narrow our focus. This does not sound too bad, right? After all, it is good to be focused in order to stay concentrated on a specific task and not get distracted by secondary aspects. However, in reality this is good only for activities that use the left part of the brain, i.e. for simple tasks that do not require creativity. But, as Daniel warns in his book, for complex and conceptual tasks giving a specific and measurable objective can blinker the wide-ranging thinking that is necessary to come up with an innovative solution. For example, if someone has a target to increase the revenue by 5%, they will draw a plan to achieve a 5% growth and no more. Consider that if they did not have that specific growth number, most probably they would think of many different ways of achieving growth, and most probably they would increase the revenue by more than 5%.
Another problem with specific and measurable goals, in my opinion, is that reaching them becomes the only thing that matters. Some people would prefer shortcuts to get there, even if it means making ethical compromises. On a larger scale, this may cause systematic problems for the organization: unethical behavior, increased risk taking, cooperation between the teams may deteriorate because it is not that unusual that the teams get conflicting goals that might be the source of inter team tension, and last but not least, general motivation might decline.
“Give a manager a target and he will do everything to achieve it. Even if he has to destroy the company in the process” by W. Edwards Deming
Personal goals that people set for achieving mastery are usually healthy. But goals imposed by others, such as sales targets, quarterly returns, standardized test scores, etc. can, at times, have detrimental side effects. Therefore, you must be careful when you set goals in your organization. Please, do not take me wrong, I believe we must have a direction, a company goal, in order to know where we are heading. But I really am skeptical about the SMART model. What do you think about this model? Let me know your opinion :)
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Agile Localization - Outplay the competition, enter new markets and grow Internationally
Hi guys! This will be my last post this year due to Christmas season. I would like to take this opportunity to present my new personal project. Together with my two colleagues, Vasco and Wim, we are going to write a book about Agile and localization. The general overview of the book can be found here.
The people who know me understand that I am very passionate about Agile. So, we would like to take an Agile approach in writing our book. It will remain to see if this experiment would be successful, but since I have this idea, I would like to try it out. Put simply, writing a book is a creative process much like developing software - at the end of the process there are potential customers that would buy the final product. Therefore, why shouldn’t we write a book applying the methodology we use to develop a software product?
Our idea is simple. Like in Agile software development, we are planning to write the book in iterations, which means that we would not follow the traditional pattern: first write the whole book, then publish it and only then get the feedback. Instead, by the end of each such writing iteration we want to release the increment of the book we wrote and get the feedback from the public. Like in Agile software development, the feedback will be integrated into the book to improve it. Every time before starting a new chapter, we will communicate its topic to our audience and invite our followers to a discussion about what they think is important to include in the book. Naturally, the book will have the main story, but the idea is to adapt the book to our “readers´ needs”.
The localization of the book will also be part of this incremental process. To have the book localized for a particular market, we would not need to wait for weeks until the product would be released in English first. Instead, as soon as the iteration is finished, the released increment of the book will see the light in English and in some other languages, too. If we really believe in this concept, there isn’t a better way to prove it than to apply it in our own book.
We are starting this project in January, and we would highly appreciate all the feedback from you, guys. If you are interested in our project, let us know! Let’s use this blog for communicating and collecting your thoughts about the book. Another thing, we would highly appreciate if you could tell us how much you are prepared to pay for the final product – the finished book. This would give us an idea about the price range for price-tagging the book, please, leave your comments here. Another way to leave your comments will be using our NPS system. Some weeks ago I wrote about NPS, you can find the post here. Before we start releasing the first chapters we will have in place a system where you can leave your NPS score.
There are a number of other issues that we still have to solve, but being truly Agile means that we will be adapting along the way and tackling issues as they arise.
Now, the only thing missing is your initial feedback. What do you think about all this, guys? Do you think this could be a cool project to be part of? Would you like to take part of this project?
Look forward to your comments ;)
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
D5 Creation