I did some research a while ago about what a cross technology Microsoft platform developer would need to have in order to be up to date on all platforms and across technologies. [Web, Windows, Client web]
PDF below
Modern Microsoft Cross Skilled Software Development Consultants Should K
Ok I admit it, if you know me you know my spelling is awful , but at last there is hope!
A new add-in for Reshaper has been released called Respeller. The following blog post goes into detail http://blog.jetbrains.com/dotnet/2013/01/14/respeller-a-spell-checking-plugin-for-resharper/ but I have included some images below from my own installation just to wet your appetite.
You arrived at work, with your stylish 6 different flavours coffee or super deluxe Fiji mineral water, you sat at your stylish desk. On the walk to your work station you spotted the other girls glancing at your funky jeans and stunning messenger bag, containing the slimiest, meanest, fastest Laptop ever designed for a world class gamer cough ! Developer.
You open up your sticker decorated lid of your mobile super computer, your Roccat Kone / Razor mouse gently running different colours along its go faster strips, let the magic begin.
Then you punch up Visual studio and you are assaulted with grey interface your granddad wouldn’t have even found trendy, your day suddenly looks like a drag.
Or Not!
Check out the screen shots below…
We can funky it up with more colour options !
All thanks to this visual studio extension: http://visualstudiogallery.msdn.microsoft.com/9e08e5d3-6eb4-4e73-a045-6ea2a5cbdabe
Also we can go full screen with a quick shift + alt + enter
Yes but this isn’t proper full screen what about the menu ?
Ah I have a fix for the pesky menu bar, this extension : http://visualstudiogallery.msdn.microsoft.com/bdbcffca-32a6-4034-8e89-c31b86ad4813
The result , true full screen
That’s all peeps
hugs
Katie
I have been thinking about this for a while about some of the Agile engagements I have had and I have started to ask myself the following questions which I thought I would share.
Has the common understanding of Agile become corrupt with wide spread adoption and modification of scrum, is scrum the new waterfall?
If we look back at Agile’s first principals, I do not believe they called for procedurally heavy process yet I find teams losing 1/4 to half a sprint because of so called scrum rituals.
A further worrying symptom is that teams seem to be forced into decisions they don’t really want to make upfront but they are given no choice and no development time to explore the options. Story’s / requirements get played at risk but everyone is shocked when the supporting estimates are proved to be meaningless.
Was this really what was intended when the agile manifesto was formed?
Do we now have reason to look more to XP and lean and go back to basics and develop truly adaptable and fast development principals?
Have we lost base skills in terms of high quality TDD , Emergent design, semantic code , good CI , continually demoable and releasable code. What I mean to say is have we embraced the Project Management side of Scrum so much, that the technical discipline that allowed us to code without safety nets, to code with minimal process, has fallen away?
How often do I hear “well we would of refactored that” or “we would of tested that” and then we have the famous “ we would of spiked or researched that” – BUT WE DIDN’T HAVE TIME and we have a dead line. Yet the same team will use 4-5 man days doing scrum meetings. To me this surely is open to questions in terms of priorities.
These are the questions that keep coming around and around, so thought I would share in case you, like me can smell the herring because to me it seems to be a little rotten.
I recently downloaded the Visual Studio 2013. One of my responsibilities as a consultant is to make sure I am up to speed with latest tools and technologies in the Microsoft development space. I was excited to see what Microsoft have brought to their already solid and feature rich tool.
The issue I often have with new tools and programing concepts is where do I start? I generally have limited time, so I like to get to the information quickly with out having to wade through all the marketing fluff. To this end I have compiled this document which follows my own initial investigations.
All my comments moving forward relate to Visual Studio 2013 Premium preview, with Resharper 8 installed + python tools.
Visual Studio
http://www.microsoft.com/visualstudio/eng/2013-downloads
Resharper
http://www.jetbrains.com/resharper/
Python tools
http://www.hanselman.com/blog/OneOfMicrosoftsBestKeptSecretsPythonToolsForVisualStudioPTVS.aspx
I will not attempt to rewrite the information that is already available on other blogs, but will provide links to the blog posts as well as extracts. Really this post should act as a launch pad for your own investigations.
It is really encouraging that Microsoft has brought direct 3D into the main stay of the tool to support a rich graphics experience across Windows Store and Windows Phone Applications [8]. Direct 3D has been seen in the past as a little bit of a black art. My hope is with better tool integration more people will brave the unmanaged code world and write stunning visuals that don’t have their performance knee capped by managed wrappers.
Links:
[Extract]
Operating system and SDK requirements
“The Windows Software Development Kit (SDK) for Windows 8.1 Preview installs the runtime components that are required by Graphics Diagnostics, and supports development for Windows 8.1 Preview and Windows 8. To use Graphics Diagnostics on Windows 7 and Windows Vista, you must install one of the following SDKs:
Windows SDK (version 7.1)
DirectX SDK (June 2010)
Graphics Diagnostics supports apps that use Direct3D 10, Direct3D 10.1, Direct3D 11, Direct3D 11.1, and Direct3D 11.2, and provides limited support for apps that use Direct2D. It does not support apps that use earlier versions of Direct3D, DirectDraw, or other graphics APIs”
[Link]
http://msdn.microsoft.com/en-us/library/vstudio/hh873207(v=vs.120).aspx
[Extract]
“You can capture graphics information from your DirectX-based app so that you can use Visual Studio Graphics Diagnostics tools to diagnose rendering problems.”
[Link]
http://msdn.microsoft.com/en-us/library/vstudio/hh708963(v=vs.120).aspx
Although not directly related to VS2013 I felt this article was vey helpful as well.
[Extract]
Add new features, like date/time pickers and enhanced navigation support by using the new XAML controls. Updates to existing controls make them simpler to use and more versatile. These new and updated controls make it easier than ever to create a full-featured app.
[Link]
As we know with cutting edge tools not yet in release there are a few hoops to go through. It is recommended you read the links below to look at development on windows 8.1 and retargeting apps form windows 8.
[Link]
http://msdn.microsoft.com/en-us/library/windows/apps/bg182410
[Link]
http://msdn.microsoft.com/en-us/library/windows/apps/br211384.aspx
[Link]
http://msdn.microsoft.com/en-us/library/windows/apps/hh738343.aspx
MSbuild 12 now ships with VS2013 and more importantly MSBuild is now installed as part of Visual Studio as opposed to shipping with the .net framework. However it can be downloaded on a stand alone link.
Find out more about MSBuild 12
[Link]
http://msdn.microsoft.com/en-us/library/vstudio/hh162058(v=vs.120).aspx
As a developer who lives on the keyboard and avoids the speed sacrifice using the mouse brings like the plague, I find some of the improvements below to be a fantastic bonus to my developement experience. I use about 5 different machines for developing software and it is a real bonus now to be able to associate them with 1 windows live account.
[Extract]
The Visual Studio IDE has some important changes—improved icons, more contrast in the user interface, the ability to search the Options window directly, and other enhancements
[Extract]
The new connected IDE uses your Microsoft account to connect to your Visual Studio profile, including your Team Foundation Service account. The first time you start Visual Studio, you supply your credentials. Based on that authentication, Visual Studio finds and applies your license and synchronizes your settings (such as fonts, language preference, and keyboard settings) across all of your computers. For more information, see
[Link]
.http://msdn.microsoft.com/en-us/library/vstudio/dn135229(v=vs.120).aspx
[Extract]
Aliases provide a means for entering a command into the Find/Command box or Command window by shortening the text needed to execute the command. For example, instead of entering >File.OpenFile to display the Open File dialog box, you can use the pre-defined alias >of.
Type alias in the Command window to display a list of the current aliases and their definitions. Type >cls to clear the contents of the Command window. If you want to see an alias for a specific command, type alias <command name>.
[Link]
http://msdn.microsoft.com/en-us/library/vstudio/c3a0kd3x(v=vs.120).aspx
[Extract]
You can use the Peek Definition command to see code definitions without switching away from the code you’re writing. Peek Definition and Go To Definition show the same information, but Peek Definition shows it in a pop-up window and Go To Definition shows it in a separate code window. Go To Definition causes your context (that is, the active code window, current line, and cursor position) to switch to the definition code window. Peek Definition allows you to see the definition and move around inside the definition file and still keep your place in the original code file.
You can use Peek Definition with C#, Visual Basic, and C++ code. In Visual Basic, Peek Definition shows a code definition window only for elements that are not part of the .NET Framework; .NET Framework elements are shown in the Object Browser. Peek Definition is not shown for language keywords.
[Link]
http://msdn.microsoft.com/en-us/library/vstudio/dn160178(v=vs.120).aspx
The changes to the scroll bar are one of the most exciting changes in my view , i love the document map mode seen in the second screen shot. The document map mode is one of my favourite features of sublime [http://www.sublimetext.com/] im so glad to see it in Visual studio.
[Extract]
You can set up the scroll bar to show code changes, breakpoints, errors, and bookmarks.
Open the Scroll Bar options page (Tools, Options Text Editor. All Languages or a specific language, or type scroll bar in the Quick Launch window).
Select Show Annotations over vertical scroll bar, then select the annotations you want to see. (TheMarks option includes breakpoints and bookmarks.)
Now try it out. Open a large code file and replace something that occurs in several places in the file. The scroll bar shows you the effect of the replacements, so you can back out your changes if you replaced something you shouldn’t have.
Here’s how the scroll bar looks after a
[Extract]
The scroll bar has two modes, bar mode (the default) and map mode. Bar mode just displays annotation indicators on the scroll bar. In map mode the lines of code are represented on the scroll bar. You can choose how wide they are and whether they show the underlying code when you rest the pointer on them. When you click a location on the scroll bar, the cursor moves to that location in the code. Collapsed regions are shaded differently; they are expanded when you double-click them.
On the Scroll Bar options page, select either Use Bar mode for vertical scroll bar or Use Map mode for vertical scroll bar. You can choose the width in the Source Overview dropdown.
Here’s how the search example looks when map mode is on and the width is set to Medium:
[Link]
http://msdn.microsoft.com/en-us/library/vstudio/dn237345(v=vs.120).aspx
The tighter integration with GIT which i consider to be the best source control option currently available is hugely welcome.
[Link]
http://msdn.microsoft.com/en-us/library/vstudio/hh994655(v=vs.120).aspx
I have not covered all the functionality but i hope this has given you a flavour of how awesome visual studio 2013 is. I encourage you to download it and explore.
Katie
This is the first article in the Agile Thinking series. The series has been inspired by real life experiences, working with teams who are trying to work in challenging environments that for many reasons are not friendly to Agile adoption. Still the teams battle on trying to change and do as much good as they can within the environmental and contractual limitations.
We believe it is a myth to say that Agile cannot be applied in all software development environments, sometimes it just takes a little work and some negotiation and compromise. This range of articles aims to make no judgments but to present experiences and techniques for working in these Wild West style environments.
We give an example of what one of these environments might indeed look and feel like in this article written some months ago: http://www.cloud-coder.co.uk/blog/index.php/2012/11/agile-or-wagile-discussion/
We hope you find this series of articles challenging and engaging if a little non-conformist.
We believe the best approach we can take in this article is to look at a scenario. We will aim to present situations we have encountered in the past and generalize the context to cover wider audiences. While there is no magic bullet for any of these situations we will attempt to present some approaches to each, which hopefully will become talking points for teams in similar situations.
While the scenarios here are based on our experiences they do not reflect any particular engagement.
The company and product
The company has a number of products that are unbranded and considered white label. The product is then sold to 3rd parties as part of licensing / SAAS style arrangement. The 3rd parties then use the products for direct sale to the general public via a number of interfaces:
· Electronic Point of Sale [EPOS] – vb6 application
· Web [Ecommerce] – .net framework V1.1 web forms
· API [3rd party systems connect] .Object C
The company had offices internationally in Australia, USA and Europe. Customization for a given client was performed by the local office. Development of the core products was centralized in the UK, utilizing a development team of 30.
Deployment, administration and support was performed by the local office and local technical teams as well as design agencies working on the clients behalf.
The product code base had been patched and iterated on top of with no concern for maintainability. Basic patterns and practices such as the SOLID set and any form of Test Driven or post code Test development had not been implemented. Reuse was not a priority and code duplication had made the code pathways chaotic and difficult and in some cases impossible to trace execution. No form of documentation had been kept and the code was littered with outdated and confusing comments. Source control was undisciplined and most of the product set couldn’t be built from source without post compilation hacking. The POS products used controls which were no longer in production and were unsupported.
The development team had taken the decision 18 months earlier to redevelop the whole product suite from the ground up in .net 2.0 using Winforms and a Webforms. They decided to reverse engineer the product suite into a set of requirement documents, prior to having the full set of requirements the business were told a number of statements.
· The business would have new maintainable products which had the same feature set as the current product set, plus a delta from the current set to the full backlog that had mounted up over a several years.
· The development could be done with the current head count.
· There would not be any releases of any of the products for 18 months, while the work was undertaken.
Katie’s Note – Although this situation might seem extreme, it is in fact common place in older product teams. It is normally motivated by a need to replace a product set which is still evolving and generally failing to perform under load; we quite often see huge support footprints and budgets associated with this type of product.
The business, the support team, the sales team and the development team are all in agreement that it must be replaced and in a tight time line. The combined product team is generally under huge commercial pressure with no willingness to undergo a staged release cycle. A classic statement you might hear from business in this sort of situation is “Just make it do what it does now, and all of the X feature set as well. We need it by the end of the year, you can’t fail”, whenever we hear statements like this we push back for a full discovery process prior to initial development of the first iteration and we make sure expectations are set and written down between business, sales, deployment and the development team.
It should also be noted that in situations like this it is common for either an ineffective Quality Assurance team to be present or for no QA team at all to be employed and for developers to be performing their own testing. We also see practices such as hot hacking on live sites and ad hock patching of live servers.
It is important to remember that all elements of the invested product team will be under severe pressure and have generally been driven to this point by desperations and rational thinking or reasoning might not be a governing factor in the decisions they make or the conversations being held internally.
What happened over the next 2 years?
The business green lighted the redevelopment, the development team ploughed forward diving into code with the CTO directing by pair programing with the developers. No plan or documentation was produced, the Project Manager continued to gather requirements and fed them into the JIRA back log.
The business and the sales team, with no guidance as to what the new product would contain, sold every feature they could dream of when speaking to potential client’s. Clients were on boarded on to the old system with promises of the new super system within 2 years.
Factors that came into play most of which were not considered at the project inception:
· The products turned out to be very hard to deconstruct and the code was very unreadable and much of the product had not been worked on for a number of years.
· The code modules had no separation of concerns very little code could be isolated or replaced in situ.
· The maintenance of the existing product, plus an increasing user base triggered by the new sales activity and promises being made to new clients, ate 70% of the development team’s capacity with no increase in head count or resetting of expectations.
· At some point during the life of the product set, someone had decided to drop all the foreign / primary key relationships with in the huge database that supported all the products. They had also randomized the table names to obfuscate them. The net effect of this was that the stored procedure which contained a great deal of the business logic were the only real statement of data truth, this caused months to be spent trying to map out a data schema and understand the data interactions.
· The UI, Data and Business logic code was spread and intermixed across layers, this prevented opportunities for replacing code horizontally layer by layer.
· The development team did not have the knowledge or skill bank to move to the technology set purposed by the CTO. As such the work which was undertaken was slow and the end result was still of the same quality stamp as the code it was supposed to replace.
The end result of this combination of factors was that the project got behind schedule. Initially this was not made visible to the business who continued to set expectations with clients, thus the pressure on the development team increased for early delivery. Eventually it became obvious to all parties that the project was nowhere near complete. The impact of non-delivery was to send shock waves through the organization, staff members left taking embedded knowledge with them and the sales team increased the pressure on the business to deliver the new features even if on the old code base.
The CTO resigned, this caused a focus point for the business and they decided to take action.
He spent day 1 understanding the business position; resources available, time frames and working with sales to try to produce a holding statement for the client base to try to remove some of the immediate pressure. This included communication coaching and assistance with public statements.
Working with the development team to understand the moral and other issues in the team. Producing a management report, including action points for increasing team moral. Prepared a brief for the CEO to deliver to the development team which was designed to base line the situation and reduce the heat in the interdepartmental relationships.
Communicated with the international teams and issued reassurances. Sketched out the high level steps of an action plan to perform a delivery within the next quarter.
Katie’s Note – Quite often the first job in a failing project is to create a holding position and to reopen communication channels. This generally involves telling people things they do not want to hear. However, as long as you have a plan to move the situation forward and fresh credibility, it is perfectly possible to have sensible conversations even with upset people.
It is important to create space within which the team can breathe and the project can be given a new shape, this generally involves easing the pressure across multiple verticals and reopening departmental communication channels.
Full Architectural review of the existing systems, the end product of this was a power point presentation outlining the main problem points within the current architecture and an architectural map document.
Positioning conversations with the business, presenting the dynamics of the current situation and talking about potential ways forward. The end result of this conversation was to abandon the rebuild project and develop features on the current code base. Where possible it was decided to use in place refactoring to replace some of the existing code base. It was also agreed that a visible project management approach was needed and that the business would need to see some fast wins. With all of the above in mind Katie pitched an agile approach to the development team, after some deep conversations it was decided that a hybrid agile approach would be used and that the existing Project Manager would work with Katie to produce story cards for the new requirements.
The next 2 days were spent isolating features from the backlog and removing duplicates the end product of the exercise was the production of a word document with a title to represent each feature detailed as follows:
|
Feature Title |
|
|
Feature Description |
|
|
Feature Relative Size |
|
|
Risk |
|
|
Dependencies |
There was a set of physical cards created using this template to describe the proposed features.
Katie organized a group of stake holders representing each areas of the business and the interrelated departments. The stake holders over a number of meetings facilitated by Katie and led by the Project Manager were encouraged to play a high level planning game.
Katie’s Note- To reach day 7 involved a lot of empowerment of the existing team. It is important in these situations to try to restore the rightful place of the team elements, and to support and facilitate the existing team back into a position where they can communicate between each other, and with the business elements. One of the tools to achieve this is to hold an initial retrospective so the past can be discussed, actions identified and then the team can move on.
What is a Retrospective – http://www.amazon.co.uk/Agile-Retrospectives-Making-Pragmatic-Programmers/dp/0977616649
As a consultant my job is not just to get the project back on track, but to leave in place a competent and empowered team. It’s very important the team depends on itself and does not become dependent on the consultant. The consultant role is rather as an ‘agent of change’ and should always stand slightly apart from the production team and keep objectivity.
Katie and the Project Manager distributed a word version of the features to each stake holder along with donuts and plenty of coffee, the meeting was introduced and the objected set, the meeting was time boxed to 1hr. The master set of feature cards were then spread out on the table each card was then spoken about in brief detail and any questions answered, the key question was then asked “Does anyone want to champion this feature?” if no one was prepared to it was torn up and thrown in the bin, if someone was prepared to champion the card then it was given to the stake holder.
After the initial sort of the feature cards had been performed, the group were left with 30 cards, Katie then told the group they needed to work out between themselves in what order the features were played, Katie and the Project manager then left the room setting a time limit of 30 minutes for the group to discuss and decide the order of work.
Katie and the Project Manager returned to the room to find an ordered deck and a happy set of steak holders who main question was then when will we see the first featured completed. Katie promised to break down the first 2 features and run an iteration planning meeting, in the next 2 days and feed back with a progress report. The current plan is for the first iteration to start by the end of the week, everyone broke up in good spirits.
Katie’s Note- It’s possible that a high level planning game doesn’t fit all situations , but what is important here is getting the business stake holders involved in the planning and making decisions about prioritization, each from their own perspective. The point of note here is do not give deadlines for feedback you think you might break, its important if you say I will come back to you with XYZ on this date , that you keep your promises.
What has been achieved in the first seven business days?
· Architectural assessment
· Alignment of the business view as to the real state of the project
· Communication channels opened up between the different areas of the business
· Air cleared retrospective held
· First set of requirements broken out into actionable items and prioritization responsibility distributed to a group of stake holders.
· Project Manager empowered
This is pretty typical of the first week of an engagement of this type, so far this engagement is following a very healthy pattern. The next stage is to plan an Agile cycle with the team and implement correct tooling and support for the team. Once this support is in place we can then look at Patterns and Practice’s and the technical elements of coding inside an older code base.
Katie’s Note- It’s important at this stage not to overload a team but also to establish and keep a momentum of change happening, the worst thing that can happen is you hit a blocker and stagnate. For this reason do not use linear planning; always have a backup plan that you can switch the team to. As an Agent for Change in these initial phases it’s very easy to become personally over loaded; I find List’s help. It is also important to take down time. For instance take your lunch hour go for a walk, do fun stuff after work and under no circumstances should you take your work home with you. It’s important to remember the team is dependent on you, it is key that you do not get to a point where you cannot process or think objectively. On a side note it also helps to have a support system in your life. It doesn’t matter if this is a group of close friends or a loving partner or perhaps an understanding cat, being an Agent for change can be a lonely and challenging place at times.
One final note of personal Qualities , you cannot afford in this initial period to have a personal bad day. It is better you stay at home than appear to the team that you do not have everything 100% under control. It’s very important you walk with 100% confidence and appear at all times to be filled with energy and enthusiasm. Remember the team is likely to be in a beaten up state from what has happened in the past they need to look to you and know that everything is sparkling bright and there are no hurdles they cannot now get past.
Individual Maintenance – It is important to find time for each member of the team, take them to lunch find out how they feel it is going. Give them an opportunity to express their fears and thoughts in a free environment. Take actions from these meetings and personally fight their corner where needed to try to provide the working environment they need to function as part of the team.
Finally don’t forget the donuts! Celebrate every small success as a team, do provide team lunches, donuts, team drinks etc. at every excuse. Team cohesion is the most important goal to continued success it is important the team feels like an extended family, one unit.
The day starts with the first team stand up meeting. We follow a very simple format members speak about:
· What they worked on yesterday
· What they will be working on today
· Any blockers
After the stand-up meeting Katie and the Project Manager did a full team huddle and fed back on the planning meeting, discussed in brief the features that had been selected as the first 3 to be attacked and announced their plan to hold a Team Iteration Planning Meeting the following day.
Katie then worked with the lead developer the project manager to break out stories from the features selected in the High Level Planning Meeting.
Katie’s Note- Normally this would be the job of the Business Analyst , but quite often you find in these situations that one is not employed although this is a role experience tells me you should push to be filled ASAP.
A story is a breakdown of a feature into more granular requirements, the language used to define the story varies from team to team as does the costed complexity; to put this another way the size of the story divisions within the feature. The following recipe is based on what I have found most effective when working with teams but is by no means exclusive of other methods, there are after all many ways to cook a fine chili.
Katie wrote up the first feature on the white board. Katie then started interviewing the team, driving them to talk about the key parts of the feature. He grouped them on the white board in to word groups. He then picked on the first common pattern of words and started to write stories around the word groups in the following format.
As a ….
Given that ……
When I…..
Then I Expect….
He used “And” where it made sense for concatenation and where stories became complex he wrote a header story and broke out scenario statements below.
|
As a Registered UserGiven that I am not logged in And I am at the home page When I browse to the product page Then I expect to be challenged for my credentials Scenario [Valid Credentials entered] ….. Scenario [Invalid Credentials entered] ….. Scenario [No credentials entered] ….. |
When the group had finished breaking apart the stories the Lead developer guessed at the size of each, where a story was over 3 days it was split into smaller stories.
· If the story contained scenarios it was relatively straight forward to extract the scenarios in to separate stories
· If the story contained highly technical elements , the team were able to extract a number of technical stories
· If the story was simply too large and had to many moving elements this was more difficult to split up, but the 3 day rule was stuck to.
The stories were then put in priority order and any interdependencies noted on the story , when the team was happy with the stories the Katie and the Project Manager then wrote out the stories onto A5 index cards and entered them into Jira as back log items, noting the Jira number on the physical card.
The planning team was now ready for their first iteration planning meeting with the larger team.
Katie’s Note- I have found it to be very important to perform the initial sizing exercise with a developer element present. This really does help you to get the size of the stories correct, it is also important to set a limit in terms of story size and to stick to that limit no matter what other pressures there might be. It is worth remembering that a larger a story is the more Risk is carried in the story. If it is too big you will end up with the developer/s who pick up the story feeling like they have to climb a mountain. It is important however to remember this is guide sizing only and when you enter the planning meeting the team may resize the stories again (hopefully this doesn’t happen too often). If this does happen then the Planning team need to be flexible and be prepared to either withdraw a story from this iteration or to split it on the fly.
In a lot of cases we used Jira as this was is the in place requirement management system , however Jira in my opinion struggles to model an agile process. This can be improved by bolting on Green Hopper [
http://www.atlassian.com/software/greenhopper ] to your Jira installation. However this is still a compromise compared to more Agile requirement management systems such as Mingle from Thought Works [ http://www.thoughtworks-studios.com/mingle-agile-project-management ]. An additional note on Team Foundation Server from Microsoft, we have found that the default templates actually introduce complexity to a team’s simple Agile cycle and planning. It’s important to remember that a tool should work the way you want to work. You should not have your teams working habits dictated by a tool. In short if you are to adopt TFS please spend time and budget making it fit your process. It is my opinion that thoughts works Mingle is the ultimate in flexible requirement management solutions, but it does require time and effort to fit it to your process. Unlike TFS it does not dictate rigid process upon the team, but due to its flexibility it is not usable straight out of the box so to speak, excluding for the most basic of projects. Normally I would advise a team to budget 2-4 days to configure a Mingle instance pared with Thoughtworks pre and post-sales support, which has always been excellent.
The Project Manager is taking a break to go over the requirements and make sure he understands them in depth, ready for tomorrow’s requirement management meeting. Katie is now turning his mind to the technical challenges of implementing new functionality inside VB6 while consuming best practice. Katie has prepared a couple of brown bag sessions for the team he will present today, both will include a live coed example.
Sessions
· T/BDD covered in this post – http://www.cloud-coder.co.uk/blog/index.php/2012/11/step-by-step-guides-getting-started-with-white-box-behaviour-driven-development/
· Making C# classes COM visible and consuming them from within VB6
http://juststuffreally.blogspot.co.uk/2008/02/steps-to-make-your-net-dll-useable-from.html
http://blogs.artinsoft.net/mrojas/archive/2010/06/23/exposing-c-classes-thru-interop.aspx
Katie then showed how both techniques could be used to produce test driven assemblies in C#, which could be used to replace huge swathes of functionality in the existing VB6 application, whilst keeping the forms and interface consistent with the user’s existing expectations. He explained that this form of black box refactoring is highly effective for replacing existing applications from the inside out, when the application must be kept in a deployable state.
Katie drew the following diagram on the white board to illustrate.
He then explained that they could use the new functionality required to replace the sections of the existing logic with C# test driven functionality. They could then make them COM visible and consume from them the existing VB6 form’s and take the opportunity to migrate the business logic that exists in the current forms plus the new logic changes to the test driven C# assembly’s. He also explained and showed an example of using C# and XAML Controls to provide new views which could be wrapped in the existing VB6 application.
The development team spent the rest of the day learning Pairing skills and how to write code from a Test First Perspective using the following sample exercise [https://www.box.com/shared/3hbnko03d7 ] Katie tripled with each pair helping to teach technique and approach.
Katie’s Note- It is really important to teach solid foundations. A good place to start is with TDD but over time you really want to promote SOLID principals as a minimum [http://www.blackwasp.co.uk/SOLIDPrinciples.aspx ].
The iteration planning meeting started with the project manager presenting each story in sequence , he also presented Balsamiq Mocks [ http://www.balsamiq.com/ ]images where they added clarity, and other artifacts such as excel spread sheets where this added important information or context.
The team then voted on the size of the requirements the numbers which were recorded on to the card:
· Quality Assurance Size [ How long it will take to test the requirement ]
· Development Size [How long it is estimated to develop ]
Katie had agreed an initial maximum size that they would play in their first 2 week iteration with the team. When this was reached the Project Manager, also acting as the customer representative in this case, had to decide which story’s to push to later iterations.
Final Comments
This article has attempted to show how within in 11 days you can turn a project around. Obviously this is not the end of the story so to speak, but the rest of the engagement is covered elsewhere under the many good posts on Agility and how to run an agile process. What we have tried to show in this article is how to get a failed project back into a state were the Agile life cycle can be applied. We hope you have found this article of use and engaging.
Introduction
This post represents the first half of a pair of posts which will attempt to lay out some fundamental techniques which i have found helpful in delivering projects that are on time and fit for purpose, in this first post i would like to examine the difference between Agile and what is commonly referred to as WAgile. In the second post i would like to talk about requirement gathering using stories and prototypal design.
At the heart of Agile techniques is a principal of known as people over process, let us for a moment focus on one of the intrinsic component’s of this principal – ‘Collaboration’ – when we collaborate with each other we get more done, this is a historical fact proven in many aspects of life including great engineering achievements from the channel tunnel through to huge military campaigns.
When we collaborate in the Agile setting we need to enter a mind set which can be quite alien to traditional project management, due to the blame avoidance culture we typically find in hi $$ projects we tend to find abstraction and deflection in use rather then clarity and inclusion, this is generally driven by the fear of ‘Showing ones dirty washing , as it were’.
For projects to succeed under the Agile banner we must become a team composed from a number of organisations working to achieve an end goal ‘ producing a fantastic fit for purpose deliverable’ for this to be really achieved the boundaries between roles within the project ecosystem and their associated rights and privileges must become so blurred that typically in time they become background noise and new project centric roles spring into place which are flexible and distinct from the persons employing organisation. In short the team becomes a cooperative matrix of team centric players within the project ecosystem, rather than employees of one of the contributing companies.
If you do not feel it is possible to facilitate this type of relationship with the client and the other parties involved, other techniques might come into play such as the use of a ‘Internal Customer’ who can be the bridge between the client and the team. However this is not optimal and many projects find themselves gradually slipping into a waterfall style methodology consequently blaming Agile for a failure when in fact they were not practising agile but a hybrid methodology that is classically referred as WAgile process – see the diagram below for how this might look.
Diagram : WAgile in action
Within the Agile space there are 2 primary approaches to Agile Development
It could be argued that there are other front runners such as DSDM and then we must also consider the LEAN methodology sets as well, the distinction between different flavours of Iterative development techniques is becoming increasingly more blurred as this group of methodologies gather a growing number of converts each contributing their distinctive flavour to the community.
However ‘What is Agile?’ is beyond the material I wish to discuss in this post , so let us instead accept that there are a number of buckets of techniques which all at their heart have the principals of the Agile Manifesto (http://agilemanifesto.org/) the guiding principles of which I quote for convenience below:
As you can imagine with this amount of scope for variation an agile environment can take many shapes; so instead of trying to cover each possible variation, I will provide below a diagram which illustrates some of the common factors that can be found in a Agile environment:
The biggest differentiator between the WAgile illustration and the Agile illustration is the communication dynamics between stakeholders, the team, we also see a distinct difference in the team value statements.
Commentary
The WAgile environment uses artefacts such as project plans , long meetings , vast swathes of documentation to try to provide an accountable environment were every thing is locked down to the following factors:
While there are important issues illustrated in these points, trying to mitigate them creates a huge risk to project completion. Classically the techniques used in a Waterfall / WAgile environment to constantly answer and document the above points leads to a lack of freedom and flexibility and a total inability to do what is needed to just get it done at the coal face. It should be noted that we also generate a environment of fear where people and companies are scared to take risks, once there opinions or improve quality.
With the on-going need to document everything and to have a paper trails for all aspects of the project, we find we end up creating roles within the team who’s sole job is to protect the company or shift liability onto other individuals, partners or companies. Thus it can easily be seen that in the attempts to lock down the Cost, Liability, exacting time frames and Risk – we find that making even the smallest movement in the project space has huge cost and requires layers of sign off and discussion this effectively knee caps the teams ability to flex to changing conditions and to innovate when the opportunity presents itself. All of the above leads to teams creating yet more documentation in attempts to fully lock down requirements in advance including some of the following documents which quite often make for miniature novels they are so great in length.
Worst still for the team is the fact that most of the above form some sort of reference material within the overarching contractual agreement which generally means making changes to them takes a huge amount of time, effort and stress. One of the other factors to add into the mix is that quite often the wrong people have written these documents or the right people have written them under huge time pressures – the end result is tends to be more a set of hand-cuffs as opposed to empowerment.
The Agile environment drives for the concept of people over process, as such the number of inflexible paper artefacts are reduced, meetings tend to take the format of time boxed [normally 15 mins or less] whole team meetings these are quite often known as touch point meetings. In terms of risk most teams tend to practise ‘Don’t put off for tomorrow what you can deal with today‘ This can take the form of writing technical debt cards and having a regular technical debt review cycle or more preferable dealing with problems as they pop up.
The classic Agile environment will also try to practise philosophies like ‘Better to ask forgiveness , than to ask permission’ in general the the Agile player is a brave soul who just gets in there and gets it done, he can afford to work like this because of the tight communication across the team elements regardless of discipline he/she is given further confidence by knowing that team shares:
One of the techniques an Agile team frequently borrows from Lean methodology is the concept of a [Red flag], this concept says that no matter a persons position inside an Agile team that person can raise a red flag , physically , by Email, by calling a meeting when they believe things are going to come off the rails and the effect of this action is everyone no matter their position stops and there is a conversation to put the situation right before the team continues.
The one main driving force behind an Agile team is not who’s fault it is , a true agile team even one split across organisations operates on a Zero blame culture because it operates on a understanding that everyone is doing there absolute best to achieve one single aim – Continually deliver high quality , demonstrable software that is 100% fit for purpose and it is this one aim that members of an Agile team no matter the company they represent or the horizontal stripe to which they belong in the ecosystem strive for, and this is one of the biggest differences between WAgile / waterfall and true Agile, true agile concerns itself totally with delivery not politics.
Willow @Technical Thoughts 