This is another aspect that we discovered over a period of time. At the start once we decided to follow scrum, we took each of the team, trained the team regarding scrum & team lead were trained to be a scrum master. Then one fine day we decided that everyone (dev & test) will follow scrum. A typical scrum team is self organizing. Team members pick up the task from the sprint backlog and burn them during the sprint. Each team works for the success of the sprint and adds a shippable increment to the component. And at the SOS (scrum of scrums) level all teams add a shippable increment to the product. This is the ideal situation that every one of us expected.
The reality was something different. At the end of the sprint we added an increment but it was not shippable. The bugs were found after the sprint delivery. The moment we had substantial number of bugs it cannot be called as a shippable increment. After some brainstorming we found the root cause. We took the conventional team setup and converted them to scrum teams. So we had development teams and testing teams. The development teams concentrated on adding new features. The testing teams took the last sprint delivery and tested the software. The target for the development team was to add more and more features. And the target for the testing team was to find all the bugs. Since the testing happened in the next sprint a sprint delivery became a shippable increment only after spending 2 sprints. We wanted to shorten this to a single sprint.
The solution we followed was to merge the testing and development teams together. Now a typical team contained a set of developers and testers. During the sprint the development and testing happened in parallel. Teams ensured that the bugs were resolved within the sprint. Those bugs which cannot be solved in the same sprint were scheduled in the following sprint. Now over a period of time the increment we added in a sprint became shippable increment. The lesson we learned was “development & testing goes hand in hand & scrum teams are cross functional”.
As an architect one has to interact with different stakeholders. An architect interacts with developer, tester, requirement engineer (our internal customer), fellow architect, designer and the real customer. Out of all this interaction, I feel the interaction with the real customer always fascinates me a lot. I will share one such instance here. In the recent times I visit a hospital regularly for my kid’s vaccination. The regular pattern is like we call the hospital and book an appointment. The appointment itself doesn’t contain a time slot or any waiting list number (token number). After this we need to physically visit the hospital, pay the consultation fees and get a waiting list number. Then we wait for our turn. This waiting is a painful one for all the visitors. The hospital has a nice IT system that helps them in patient management, billing, consultant management and employee management. Being a software solution provider I thought this is great opportunity. Add a module that can provide automated online appointment management (web based/mobile based). The visitors need not waste their precious time and still gets to meet the consultant on time.
I got a chance to meet the hospital head and mentioned this solution. Also I elaborated how easy it is to add such a module. He listened carefully and then uttered the following
“I know it is easy to add online appointment management to our system. But in our locality people still judge the popularity of a hospital by the amount of crowd waiting for consultation. If I reduce the crowd by introducing such a system, then it will bring down the popularity of the hospital. So having a manual appointment management system is a conscious business decision.”
I learned the reason and thanked him for the clarification. As I stated in the beginning interacting with a real customer is always fascinating.
In this post I am going to cover an important responsibility of a software architect. A software architect should know and own the big picture. The big picture is a collection of important decisions, if broken has a system wide impact. Often software teams come up with the following arguments for not having an architect
- Architects don’t code. They are costly resource.
- We need the architects at the start of the project then we don’t need them.
- Architect just write power points and don’t understand the details.
But in reality a software architect is not a role with all the details. This role works with all the abstraction of abstractions. A software architect is responsible for ensuring that all the quality attributes are achieved. For a simple small project a software architect may not be needed. But the moment project becomes huge and complex the team needs someone to take up the role of software architect. To do this a software architect needs to know and own the big picture. The component teams often make lot of local design decisions. A software architect should be able to identify decisions that might have an impact on the big picture. And if a local decision will break this big picture then it’s the architect’s job to communicate and do a course correction. Ok enough of abstract talk. Let me give a real world example.
I used to visit one of my friends who run a cell phone repair shop. One day a customer came to the shop with lot of anger. He mentioned that the helper broke his mobile and the camera is not working any more. My friend inspected the phone and found the memory card was filled up. There is no space left for storing a new picture. He explained this to the customer. But the customer mentioned that the camera was working until he gave the phone for servicing. Now my friend enquired the helper regarding the service he performed. The helper mentioned that as a part of service the customer asked for some songs to be loaded to the phone. The helper filled up the memory card with songs. Now my friend said to the helper that the memory card is a shared resource. At least 30% of it should be left empty. This is a basic rule of servicing. The helper freed up this space, learned the lesson and gave the mobile back to the customer. Customer mentioned “I normally don’t give my phone to your helpers directly. Next time I will give my phone for servicing only during your presence”.
In this story the helper was focusing on one aspect “Loading the music to the phone”. He decided to fill the entire memory card with music to delight the customer. But he was not aware of the implication it might have on the other subsystem (camera operations). And he broke the rule of leaving 30% space free. In real life software projects each of the component team is thinking about its component and makes such local design decisions without knowing its implications on the other subsystems. And they may break an architectural decision. Here my friend is like the software architect and the helper is like the component designer. A software architect needs to communicate with his fellow designers on a regular basis and ensure that the architectural decisions are not broken. But during the course of software architecture and design lot of such mistakes are bound to happen. During all these times a software architect should patiently course correct his fellow designers and ensure that his big picture remains valid.
The customer in the end mentioned that he wants someone to own the big picture in a subtle way. In real life software projects too we need someone to know and own the big picture throughout the project.
In the recent times I read a lot about IoT(internet of things). And the way they are going to improve our lives in so many ways. For example the story goes like
- By the time you reach home the thermostat will start the AC or the heater and setup a pleasant temperature
- The new age LED lights are connected to internet and switch on/off based on your location pattern
- The fridge finds out, there is no milk and adds a to-do entry to your to-do list to get the milk
- There will be sensors everywhere. Based on the data they will decide and act intelligently
Yes. All of this is well and good. But among all this intelligent set of things there is a dump thing mixed in. It is none other than the HUMAN. At times I feel scary how this billion of IoT is going to handle the human. I will quote one of my own examples here.
- At our home we have 2 iPods a nano(8GB) and a touch(32 GB)
- My father used the nano while I used the touch
I load the songs into the iPod using the following routine (Because of the difference in the iPod memory size)
- Remove all the songs from iTunes
- Connect the iPod to the PC
- Add the songs based on the need into iTunes
- Run the iTunes sync
- Disconnect the iPod
Sometime back I was travelling to USA for a long term. As a part of the travel preparation I made sure I loaded my entire music library into my iPod touch. One check list item done and ticked. My father requested me to load some of his personal favorites into his iPod nano. I did my regular routine and gave the iPod back to him. He thanked me and verified all his songs were loaded. I felt happy that in between the travel preparation, I could get this small job done.
I packed my bags and reached USA. After a week I thought of listening to some of my favorite music. I took my iPod touch, charged it and connected my headphones to it.
I hear some old song that was my father’s favorite. I thought maybe I added that by mistake. I shake the iPod for a shuffle. Again another old song. After lot of shake I found my entire music is missing and is filled with my father’s collection. I am wondering what has happened? I didn’t touch my iPod after the last sync. I clearly loaded all the songs myself. That was the first step in the travel preparation. I was wondering what sort of black magic has happened?
Then I found out, I turned on itunes wifi sync by mistake sometime back. So when I was loading the songs to my father’s iPod, my iPod touch found that out, intelligently wiped all the songs from its library and loaded all my father’s songs into it over wifi automatically. From the iPod touch point of view this is perfectly fine and intelligent doing all this in the background. But the outcome was a disaster from my point of view.
The problem is humans have a tendency to forget things. Until now it was my PC, internet and the so called Smartphone that has to deal with this situation. Now I am not sure how this billion IoT is going to handle this situation.
In continuation to my last post, Here is another subtle thing that I learned by practicing scrum.
The success of a SCRUM team depends on the effective sprint execution. Our typical sprint execution is like
- We have a sprint backlog. This is prepared as a result of sprint planning
- Each team member takes a task and starts working on it
- Each day in the daily stand up meeting the team member reports the amount of time needed to complete the task (it is like estimating the task daily based on the latest knowledge)
- Once completed pickup the next task based on priority
But during the retrospective meetings the team members complained about burn out. The following were the comments
- This methodology is too taxing
- I have no time for any other work other than the project
- In case of waterfall we had pressure at the end but here in scrum we have constant pressure all the time
Over the time the team’s productivity also came down a bit. After some analysis we found the problem. It was “Allocating all our time for the project during sprint planning ( 8hrs/day )”. In addition to that during the planning phase we tried putting in as many hours as possible. And during the sprint we tried to meet those numbers.
The problem was solved in 2 parts. One was from the project management side. The other was from our own.
- From the project management side they too felt this burnout and made a small change. Instead of planning for 8 hours a day, we were asked to plan only for 6 hours a day. The remaining 2 hours went for all the non project activities.
- From our side we made sure that the team brings in all time burners to table (training, vacation, holidays, supporting other teams, reading, learning etc.,).
Now the team had a constant load and we started to make predictable deliveries. In addition to this we never got the feeling of being under constant pressure and burnout. Again it’s a small correction but we learned it only during the practice.
In the past I was leading a team of 8 developers and a tester. We followed the Scrum method for close to 4 years. In this series of posts, I am planning to write things about Scrum method that I learned by practicing it. It is mostly out of my personal experience.
One of the major tasks in Scrum is sprint planning. Our regular sprint planning happened like the following
- The product owner comes up with a list of features, bug fixes and refactorings that can be taken up in the sprint
- I find out the team’s availability. (Actually taking all the planned vacations, trainings & holidays into account)
- Next we break down the features into smaller work packages
- We all sit together and estimate the work packages (using planning poker)
- Then we pick up work packages that is equal to the availability
- And finally we assign the work packages to the team members
This was working fine. But then over the time I found that we missed our team goal even though majority of the work was done. After some analysis and retrospective I found the problem was the last step.
- And finally we assign the work packages to the team members
This step of allocating the work packages to the individual team members divided the team into individual members. So if someone completes a work package the next one was chosen from the team member’s pre-allocated subset. Sometimes this created situations where a work package of high importance to the team’s success was stagnant because of an overloaded team member. And another team member is busy burning some less important work package.
So we learned our lesson and stopped allocating the work to individuals upfront. We planned the work packages without assigning a name to it. Now once someone completed a work package the next one was chosen based on the team’s priority. It also made the sprint planning a lighter exercise.
This is a subtle thing which no one taught me in the scrum master training. And I learned it after failing couple of sprints.
This is a short post that I wanted to write for a long time. It is based on an example that I mention in majority of my training sessions. Let me get to the point quick. In India there is a common practice. If you roam around in the small towns, villages and in some cities too, you can see elephants in the road accompanied by the mahout. On seeing the huge animal everyone gets excited. Especially the children gets excited and frightened at the same time. And the routine is the same everywhere. The mahout will bring the elephant near each of them and it will bless the person by putting its trunk on top of the head. Then it will beg for money using the same trunk. We pay the elephant some money which it hands over to the mahout.
In India elephant is seen as a representation of the Hindu GOD Ganesh. So people taking blessing from it is fine. But one thing that I always wonder is, the effort the mahout put in training the elephant to beg and using that huge animal only for that purpose. You may be wondering why am I suddenly writing about elephants in India. No I did not quit my software job and started learning about elephants. In the software development industry I have often seen a team asking for a costly tool (Visual Studio 2XXX, Enterprise Architect, Rational Suit etc.,). The company looks at the cost and benefit. Finally it decides to buy the costly tool.
Now once the tool is bought and handed over to the teams, I have seen lot of teams using hardly 5% of the features provided by the tool. For eg
- Use Visual studio only as a text editor with syntax highlighting.
- Use the enterprise architect to draw UML diagrams
This is synonymous to using an elephant for begging. One of my major endeavor is to use the elephant for doing things that it is meant for.
Always spend time for learning the tool and use it to its full potential.