And here It comes... the end of the first sprint

Hello everyone,

Sorry about the lack of posts lately. I got a lot of things came at the same time. I had to write my final paper to finish the Post Grad course I'm doing, planning a trip to the Brazilian state where I was born - approximate 2000 kilometers -  to defend this paper. And on top of that, I went to the hospital for a urgency procedure. Yes, I have a lot of things to write about and I hope I can get most of it done by tomorrow. So lets start.
We started the first sprint with some issues like: we have a PO - product owner the most important person in a Agile project - that wasn't so present when the project began, we hadn't set up a test and staging environment to the project and we weren't trained enough in the brand new set of ALM - application life cycle management - tools bought by the company and expected to be used in this project. That's how we attacked each one of those issues.
For the first issue we assumed that we were good to set the project priorities to the sprint. We select three stories that we thought that may brought good value to our project, notified the PO and started to develop. In the mean time, our analysts were studying the next stories we think that are good candidates to the next sprint. The only problem with that was that we chose stories that didn't bring any changes to the interface and were mostly related with back-end functionality and weren't the kind of story that make people say "Wow! That's really cool!". It wasn't big deal and we made it anyway, but this is one of the lessons we learned: choose at least one "Wow!" thing to delivery in the first sprint.

PO - Product Owner

For the second issue, we chose a shortcut that didn't turns out well. We use the development environment to do every single task from development to test to deploy. This happened because two main problems. First, it is very difficult to get a test environment set up. I really don't know why this happen so frequently in the companies I worked but it is really common. And second, we thought that we are all be present during the sprint all the time and that weren't any chance that we miss someone during its execution mainly the our senior developer that was taking care of the environment. But, as you can anticipate, was exactly what happened. Our senior developer got conjunctivitis, a highly contagious viral infection, and also got a 5 days sick note. It was chaos. The other two developers didn't know how to put everything working and we had problems to finish some activities. Second lesson: don't use a developer machine as the only environment available to the project - although this can be difficulty for us - and, most important, train at least another team member in application delivery, or you can end up in trouble if this important member gets sick or leaves the team.

Always have a backup plan

For the third issue, we just made as much mistakes as possible with the ALM tool. I was responsible for create all tasks for a virtual sprint board (and the physical board too) and because my lack of experience doing it we got what I called a "Sprint roller coaster Burndown". It was just so funny to see the graphic ups and downs that was really difficult to see any progress on the sprint whatsoever. At least the physical sprint board get all activities done at the end of the week. Lesson learned: if you are getting used to a new tool and you are sure that you will make mistakes on it, is nice communicate with the stakeholders that this can happen (we did that, and didn't get any trouble with the high management).

Our Sprint Burndown

To finish the sprint, we had the Showcase. The Showcase is a meeting where the team shows what was develop during the sprint. The PO evaluates the software delivered and approves it or not. To do that we had support from a consultant that is helping the company to get the Brazilian software maturity process similar to CMMI. She was a really experienced professional that conducted the ceremony that got to its end with no big issues. Of course we get several warnings regarding the project environment - what turned out good for us, because that made our project manager see the necessity to get it quickly. But I think that for the first experience, we did really well. And remember what I said about the lack of PO for our project? That got visible during the Showcase that he couldn't wear the hat of PO and one of our analyst got promoted to the new PO for the project. I think that was a great decision for the project and now we have someone more present to get the project to the path to success.

Sorry for the long post. I hope you enjoy it.

Best regards,

Gustavo Fonseca

Step three and a half... inception deck

Hello everyone,

Thanks for keep reading. Last week I wrote about five of the ten tough questions of the inception deck. In this post I going to finish that...

Show the solution
This one is about to draw a simple design model for the solution you are planning to build. In our project we design a BPMN collaboration diagram with the message exchange between the sales assistant and the system and also a simple architecture diagram with the systems that we are going to build and or consume. We haven't made something very elaborated because it was not the time to do it and because it is not the goal to get everything detailed upfront.
Up at Night
This is all about risks. If you study about traditional project management you know what this is about: documentation. And that is what exactly happened in our project. We have a traditional project manager and he puts all risks in his documentation to show to the higher management. We haven't participated on this as well.
Size it up
The goal here is to measure how long it will take do deliver the project. The project manager took charge on this matter too. We got to know that the deadline was 30th of November. But we also got luck because we have some functionality built up front and we need to focus on brush up the application and we think that the time will be enough to deliver if we focus on it.
What's is going to give
Trade-offs. All in life is about trade-offs. I went to Ireland in 2010 to study English. And I loved it I wish I could stay longer but I left my heart and my fiancee in Brazil so I came back. Now she is my lovely wife even though we stayed separated for ten months. That was a decision I made and I don't regret it but I had to choose. And when we talk about Agile Projects and software development it becomes clear that for many things you need to choose what you are going to give to get the project done. To this one our project manager and product owner are going to take the tough decisions and we will be here to support then. The only thing we know for sure now is that we need to deliver in November 30th.
What's going to take
We are almost there. This is last one. How much is going to cost? Who are the team members that are going to build this project? How long is going to take. In our project we have seven team members: three developers, myself as technical leader and tester - dealing mostly with automated testing and some project manager duties -, another tester, two analysts that are going to help with the UX design. The formal project manager is going to deal with the formal process and documentation and wasn't counted as a team member. And I can't give details about how much it's going to cost first because there are legal reasons and second because I don't have all numbers.

That's the way we dealt with the inception deck in my project. There are another ways to do it but I think that for our first experience we did well. We tried to answer most questions and leave some of then for the formal process and we are going to keep one eye on them - for example the risks that are identified.

That's it for now.

See you next time.

Gustavo Fonseca

Step Three - The Inception Deck part 1

Hello everyone,

We are going to start with a change. Yep, Agile embrace change and that is what is going to happen in this post. I said that I intend to write about the team but I think it's better to go to the inception deck. But first to the picture from the Agile Samurai:

Inception Deck - From The Agile Samurai written by Jonathan Rasmusson

The inception deck comes from the idea that we should ask the tough question upfront. So this is all about it. In our mobile application project, we answered five out of ten questions. Why? We have to mans responsible for the project. We have a project manager that's following the standard management practices. So, he have to do a lot of formal documentation. But he won't answer all of those questions. So we did it by ourselves. But before we discuss that I need to explain a little bit about the questions. I'll start with the first five and in the next post explain the others.

Why are we here? 

This is all about the reason that the project exists. The are a nice interesting TED talk about it and this website as well that I highly recommend you. We answered this one :)

Elevator Pitch
This is a short sentence that explain the project/product/service you are delivering. If you are planning to start a Startup, that is one of the things you should do. If you want to know more about this topic, specifically how to use it in a Agile project, you can find it in The Agile Samurai. We also did this one. It was very nice and exciting gather the team and write a sentence that defined our project. We even gave a internal name for all project VAMO (Vendas Assistida Móvel Online - online mobile assisted sales translated from Portuguese).
Product Box
I liked this one a lot as well. To answer this question we built a box for the software project we are building. The technique is explained in details in The Agile Samurai. The main objective is to materialize the product although most of the Software don't have a box for it. The box have the product name, a slogan and its main benefits. We built ours and send it to the CIO that got really excited and came to us to ask if the picture we use in the box was the picture from our product. So, first lesson "make sure that the pictures are fake to your stakeholders our you maybe have to explain it later".
NOT List
The question is about scope. What we are going to build, what we are not and what we need to figure out. We did not answer that because it was in the project planning documentation. And we get another lesson from that. One day before the first sprint planning, we have a meeting to explain what we are going to build and what we are not because it wasn't clear in the documentation. So even if there is a formal documentation, try to write this elsewhere in your project to don't get any trouble.
Meet the neighbors 
This one got us another lesson and it is related with the NOT List. The neighbors are people that are not directly involved with the project but are interested in the outcomes. They are called stakeholders in some places. And we have a little discussion with one of those neighbors about one functionality that it was desired by the product owner (more about it other posts) but was decided not to be built. To know about the people that are interested in the project is very important, and you should think about it or face the consequences as we did.

I think that is a lot for now. I hope you enjoy this one.

Have a great day,

Gustavo Fonseca

Step Two - The project

Hello All,

Let's start talking about the project and what are my responsibilities. I'm the technical leader, scrum master and sometimes project manager. I got this opportunity after a meeting with our CIO. I was, actually I still am, responsible for be the focal point the partnership between my company and one of the biggest research companies of the world. One of the topics that I'd researched was SDLC - software development life cycle - and Agile. The company I work for uses a process based on RUP - I still think it is ok to use it but I also think that are projects the can deliver better results with agile - and, because some missed deadlines start to think about change. I was frequently proposing new ways to do software testing - I was hired to be a Test Analyst - and to change process - now I'm doing finishing a postgrad degree in BPM. So they decided to give me a chance. They offer me the opportunity to participate in a project that we have to deliver a system that allows our clients to use mobile devices to sell products in our ERP systems.
I said yes and got the challenge! The team is very motivated to use Agile. One of our team members did something like that before and the others want to learn how to work this way. It is good to have the butterfly in my stomach again. The CIO have so much expectation on this project and we have a chance to change the way we do some projects here.
Now, talking about the project, we have some of the work done for another team that delivered a version of the application with limitations. We are going to improve it so it can be commercialized and used for our clients.

So, that is it for now.

Tomorrow I'll be talking about our team and the inception deck for the project.

Have a great day.

Gustavo

The first step of the jorney

Hello all,

The main reason that make me start this blog is to share my experience in being a technical leader in a project that is using Agile practices. My company is migrating some of our projects from a formal process based on RUP to a lightweight Agile process.

We just start this week and we already have a deadline, 30th of November.

I choose to use the book "The Agile Samurai" from Jonathan Rasmusson as a guide to my activities and the posts. If you want to read more about the his work and about Agile you can go to his awesome website:  http://www.agilenutshell.com/.

I plan to write every weekend about what happened during the week and have special posts after each sprint - we decided to have sprints of fifteen days. This weekend I intend to write about the project, the team and the inception deck.

As you already notice, I also start this blog to practice my English writing skills. So, I apologize before hand about my mistakes. But I hope that you may help me get better on this with your comments.

I think that is all for now.

Best regards,

Gustavo