Hesam Seyed Mousavi, September 13, 2015
Agility is the ability to twist and turn in minimum time and efforts. A fighter aircraft is Agile. It has to be, since it has to engage in dogfight with enemy fighter aircrafts and should be able to point its weapons towards the target, in minimum time. Fighter aircrafts are designed for stresses and strains due to agile movements. A passenger or cargo aircraft is not required to be agile. It does not need to change direction frequently and quickly. Once its direction is set, it can travel in that direction for hours together with no need to change direction. If somebody tries to change the direction too often too fast, then the whole structure of that type of aircraft may fail resulting in a catastrophic crash.
In the early days, software development was assumed to follow the pattern of passenger aircraft. The requirements of business were supposed to be fixed and changes if any, were not because business requirements changed, but because there was a gap in understanding the actual requirements. The process involved deciding the goals by knowing the requirements, set the direction of the team and start working in that direction. The project could go on for months without changing the original goal and the direction towards it. However during the subsequent years it became apparent that, by the time a significant number of requirements are implemented, business environment and needs of the business from the software, have also changed. Some of the requirements are no longer valid to the business. The team cannot change direction because it is not designed to be Agile. There are significant number of processes that it has to go through, before it can change direction. Eventually the Business that is sponsoring this software development, does not like it.
Since mid-90s the concept of agile teams was put forward by a few thinkers. They published the Agile Manifesto which provided the values and principles that guided the agile teams to work really agile. The main concept was to assume and embrace change. Agile teams should expect that business needs are bound to change as the business environment, which are dynamic, will change. Some other principals were to give importance to working software rather than documented requirements, technical excellence, short iterative approach that limits the plans to one iteration of maximum a few weeks etc. You can read all agile principals in the Agile Manifesto at http://agilemanifesto.org/principles.html.
To support the implementation of these agile principals, some practices evolved over a period of time. There are no fixed agile practices, they keep on growing as the experience of industry to make teams agile successful, is also growing. Some of these practices were codified for managing the agile teams and got formulated in the methodology like Scrum. Some other practices which were more technical in nature were given more importance in another methodology like XP (eXtream Programming). Number of such methodologies with preference to some practices to implement agile principals have evolved in the past few years. An agile team is not restricted to follow only one methodology, but can make combination of multiple methodologies to suite their environment and interests. For example an agile team developing some new software may use Scrum for managing the team and planning, whereas for best effort development, it may follow XP.
Before any organization decides to enable agile teams, these organizations should understand that agile is a very democratic way of working. Agile teams are empowered to be self-organizing. They are also empowered to take decision to plan within an iteration. Let me extend the example of aircrafts to make my point. Until the WWII, aircrafts were piloted entirely by a human being. This person could control the components of the aircraft to make it twist and turn. The demand for agility increased to such an extent that limit of that human being was reached. Pilots could no longer control all the components of the fighter aircraft with the agility that was required. Slowly decisions at certain components were automated so that it may not harm the aircraft and keep it flying without intervention from the pilot. A new technology called fly-by-wire came into being. In this technology, components of aircraft had computers that take decisions based upon the environment. Aircraft controlled itself so that it remained the Agile. The Pilot became only a facilitator for the computers to take appropriate decisions. Similar to that, organizations should empower agile teams to take their own decisions so that they remain most agile and receptive to any changes in requirements. The role of Project Manager should evolve into a facilitator that enables agile team to take correct decisions. I have seen many organizations across the continents (and their customers) that intend to build agile teams but do not empower the team to take any decision and continue to have a hierarchical decision structure. This drastically constrains the agility of the team.
If the organization is willing to make Agile teams self-organizing and to empower them for decision making, then there are a plethora of tools that will help agile teams to be agile. Managing the agile team is to decide which roles should be present, what are responsibilities of each role, activities that every team member does and timeline of these activities. Scrum provides the framework and guidelines for these decisions. To know more about Scrum, read the guidance provided at https://www.scrum.org/Scrum-Guide.
Team Foundation Server (TFS) 2013 facilitates implementation of Scrum by providing a process template and set of tools built in it.
Roles specified in Scrum are Product Owner, Scrum Master and Team Members. We can create groups in TFS for each of these roles. Although it is not of any significance right now, we may give specific access rights to each group when required. TFS 2013 supports Scrum by providing tools for creation of Product Backlog, Sprint Planning, and Team Capacity Balancing etc. Product backlog is created by adding required number of work items of the type “Product Backlog Item” (PBI). Entire Product Backlog can be viewed either by executing a pre-built query “Product Backlog” or by going to the screen of Visual Studio Online – Team Project Name – WORK – Backlogs – Backlog Items. I am going to stick to the second approach as for a couple of other features, it is the only approach that is available. The screenshot here shows the entire product backlog at a specific moment in time. Product Backlog is a living document that grows as new requirements are identified and added by the Product Owner. Items in product backlog are prioritized by the product owner. This becomes useful for the team to select PBIs for the sprint.
One of the important concepts before the PBI is finalized, is the validation of PBI by the customer. Product owner takes help of the team to create a storyboard pertaining to the screens that will be created to imlement PBI. These screens are just the mock-up of the UI. TFS 2013 and MS PowerPoint collaborate to provide a storyboarding tool to the team and the customer. When a PBI is opened in the Web Access, there is a separate tab for StoryBoards. In that tab, the team member can create a storyboard for that PBI.
When the link to Start storyboarding is clicked, it opens the installed storyboarding tool that is embeded in MS Project. It allows the team member to create the screen mockups. Every slide contains a mockup of one of the screens that will be built. There are shapes provided in PowerPoint to specially create the mockups of the various types of applications that can be created in Visual Studio 2013.
PBI with its linked storyboard is assigned to Product Owner or a customer representative. They can open the storyboard to give comments on it and save it back. After that, they can reassign it back to the team member. In this way the functionality of PBI is validated before that PBI is set to Approved state.
Finalized product backlog can be viewed in the TFS Web Access and may look like this:
Status of all PBIs of the product backlog can be seen from the Board view of the backlog.
Scrum process template built into TFS 2013 facilitates iterative process by allowing us to create Sprints in the iterations framework. These sprints can be of the length decided by the team or the organization. Team can set the start and end date for the sprint that is added. In the Backlogs view, the sprint that spans the current date is shown as Current sprint.
Before the team can decide on list of the PBIs for a sprint, it should have an estimate of available number of hours for the sprint. There may be some team members who work on multiple projects and cannot devote a full day, but only a certain number of hours per day for this project. It is also possible that some of them are not available for a few days in between. Such details will be used for sprint planning and can be entered in the Capacity screen of each sprint.
Team can move a PBI to a sprint by using drag and drop on the sprint name in this view itself. Each PBI can have a value for Effort which is a relative value of efforts estimation. It may or may not be estimate of actual hours required to make that PBI ‘Done’. It also has a field for Remaining Work. All the Remaining Hours of the children tasks are rolled up in this field automatically.
Some of the PBIs may not have all the details. That is what is expected by an agile team. It keeps on gathering data and analyzing it even after it has started working on other PBIs in the sprint. Unlike traditional way, all the requirements are not frozen before the work starts. This gives the team required space to maneuver. Backlog view of the current iteration may look like this:
On the right side of the screen, graphs are shown for Capacity vs. Estimated Efforts.
The image shows that the team and its team members are not being utilized to full capacity. That is natural since details of some of the PBIs are yet to be entered. Ideal situation will be when capacity of team and every team member is nearly 100% utilized. Team can put some PBIs back on the product Backlog and bring other PBIs in on the Sprint Backlog.
When the team starts working on the PBIs and their children tasks, the state of those work items is changed from To Do – In Progress – Done. Scrum provides a graphical display of these PBIs and Tasks in various state in a snapshot at a time as Scrum Board or Task Board.
As the sprint progresses, the tasks are closed and PBIs are done. The Remaining work for that sprint reduces and at the end of that sprint, it should become 0. The trend of this reducing work is graphically shown as Burndown Chart.
When the entire sprint is over, the ‘Done’ application is hosted on a server. A feedback request is created.
Now that we have seen how the agile team management works for planning and running sprints, let us focus our attention to agile development practices. Some of these development practices are part of the eXtreme Programming (XP) but we are not limited by that. We are going to visit some of those practices which can improve the quality of software that is being developed, without affecting the productivity of the team adversely.
The first practice that I would like to take up is Test Driven Development (TDD). Underlying to this practice is the concept that every bit of code that is written, should be unit tested. For clarity, the unit testing is to create code that executes the application code with parameters, for a known output. Such code once created can be executed after any change in the code of the method under test to ensure that it’s functional integrity has not got affected. There are number of frameworks that allow you to run such unit tests. Microsoft Visual Studio 2013 supports many of such unit testing frameworks like NUnit, xUnit and off course Microsoft Unit Test. It has also introduced concepts of Fakes and Shims for easier testing of methods that expect custom objects as parameters. Visual Studio 2013 also supports Code Coverage computation which is the percentage of lines of the targeted code that is being tested by all the unit tests. If this percentage is not high enough, then there is a chance that untested lines of code may contain some bug.
A twist in the tail of TDD unit testing is to write it first, even before the code to be tested is written. The whole idea is that you keep on coding the target method, just enough to pass the unit tests, that already are written. If all your unit tests comprehensively represent all the requirements from that method, then the method code that just passes all the unit tests, is the most optimum and lean, without any flab of superfluous code. It can improve the productivity of development. Visual Studio allows you to write such test and then generate the stub of the method to be tested. This improves the productivity of the Agile Team further.
Refactoring the code is another agile development practice that teams use to make code optimum. Visual Studio 2013 provides the following features that supports refactoring:
1. Rename – Name of any entity like class, method, field, property etc. can be changed and wherever it is needed like calling methods or field references, the change is propagated.
2. Encapsulate Field – A field can be converted to a property.
3. Extract Method – Code in a method that is required repeatedly or is too large for comfort, can be converted to a method. Where the code originally existed there the call to newly created method is inserted.
4. Extract Interface – From an existing class, we can generate an interface containing selected members of existing class.
5. Remove Parameter – Easy way to remove a parameter from a method. Wherever the method is called, the same parameter from the call will also be removed.
6. Reorder Parameter – Easy way to reorder a parameters of a method. Wherever the method is called, the reordering of the parameters will take effect.
Another very common practice of Agile Development is Continuous Integration. As soon as a functionality is developed by a team member, it should be checked that it integrates with the functionality of other features and does not break any of the previously written code. This is achieved by executing a server side build as soon as the new feature is accepted by the customer (can be during a demo).
Build service of TFS supports many types of triggers. One of them is to run a build as soon as someone checks-in code in the targeted project. That build can have standard workflow activities to compile code, execute code analysis on that, run configured unit tests and may also have custom activities to deploy the application. TFS 2013 encapsulates the entire process of build and deployment through the feature for Release Management that is introduced recently.
Agile is a way teams think, behave and work. Teams that are empowered to take decisions and implement those decisions based upon the changes in the business environment, become Agile. They get an edge over other teams as they accept there are changes in the needs of business and are ready to face those changes. Team Foundation Server 2013 and Visual Studio 2013 are designed to help teams to become Agile. In this article, I explained how these software’s facilitate implementation of Agile practices for managements and for development.