This is what I consider to be my list of ‘essential’ tools / skills for a serious .Net developer.
An Agile or Lean methodology
If your projects are not being delivered successfully Scrum will either enable you to start delivering software, or highlight the reasons why you aren’t.
The Scrum Guide which contains all the rules of Scrum is 13 pages long. There is no excuse for not having read it.
If you aren’t doing Scrum, or you aren’t doing it well… get some help.
Out of the box, it gives you so much. I find it incredible how many people have TFS but are only using it for Source Control.
Learn both Team Foundation Source Control and Git, and the strengths of each.
Work Item Tracking
Being able to successfully deliver value to the customer while triaging bugs requires efficient work item tracking processes and tools.
Why-oh-why isn’t everyone doing CI?
Check in your code, have a magic fairy build it, test it and tell you if you’ve broken anything – sounds too good to be true AND it only takes 60 seconds to setup!
‘Fail Fast’ is probably my favourite development catch-phrase: If you find out that the code you’ve just checked-in conflicts with some-one else’s code 2 minutes after you’ve checked it in, it’s easy to resolve the issue. If you only find out there is an issue a week later, it’s much harder.
Get your CI fairy to take the code she builds and then deploy it to a server for you.
If every time you finish a task you can send the user a link to the test server that you just deployed to and say ‘tell me what you think’. The customer will LOVE you… and you get feedback when it’s most helpful.
If you are using Azure, continuous deployment is just so damn easy.
Also, I am having a little love affair with a tool called Octopus Deploy http://www.octopusdeploy.com. Check it out!
As a .Net guy… you need to be familiar with Azure.
It’s remarkable how easy it has become to build and deploy web applications to the cloud. In 30 minutes I can create a source code repository on http://visualstudio.com, check in an MVC project and have it continuously deploying to an Azure website with both Release and Staging environments.
Check out Andrew Coates from Microsoft doing continuous deployment to Azure at FireBootCamp.
Azure is so much more than just websites… but as this is a ‘need to know’ list, I’ll force myself to not go on about how awesome Azure VMs and Web Roles are. If you take an interest in the cloud, Azure is a platform that will have you boring all your friends with tales of how cool it is.
Communication and interpersonal skills cannot be overemphasised. No matter how smart someone is, you don’t want them on your team if they can’t work as part of the team.
- You need to know how to take instructions
- You need to know how to provide feedback
- You need to know how and when to push back, and when to give in
- Sometimes, you just need to shut-up
Patterns, Practices and Principles.
This is the stuff I’m REALLY passionate about.
Building a complex application, that is still going to be maintainable after you have added features to it for several years requires some skills. My mission is to increase the understanding amongst .Net developers that the following are essential, not hard to learn, will improve your job satisfaction and your employers opinion of you when you continue to add value to his application well after other projects have ground to a halt.
This is not about swapping your SQL Database for an Oracle one!
There are many, many benefits to Dependency Injection: Here is the major one for me – you need dependency injection to ensure that your complex system is built in such a way that changes to one module does not cause flow on effects in other modules.
Typical on many projects: first 10 features get thrown together in a week, the next 10 features take 2 weeks, the next 10 take a month, and then every subsequent feature takes longer and longer because of the changes that need to be made throughout the project to implement the new features.
Dependency Injection is about ensuring you can continue to add features to your complex project.
Essential Reading: Dependency Injection in .Net by Mark Seeman
I’m not a code coverage guy. I don’t believe every single line of code needs a unit tests.
I believe the following
You NEED to be able to write great tests.
Your application should have unit tests over 100% of the code that requires unit tests.
This is a topic that I can (and do) talk about for hours, but in summary:
I write tests
- for fragile code, or code that is likely to break
for important code that you cannot afford to break
for code that is hard to read: Well written unit tests are the best form of documentation after well written code.
when writing the test provides me clarity about the code that I am about to write (slipped my TDD hat on there for a minute)
- When writing a unit test will save my boss money because it’s faster than the (damn) debugger
One of my favourite rants: It is often faster to write a unit test than to test the code you have just written any other way.
I see this a lot and it drives me crazy: I’m testing the credit card validation of my online store. I want to test the submitted card number against a regex before I submit it to the Bank.
Debugger Guy: I hit F5, wait for the whole solution to compile, the website to spin up and the debugger to attach. I then select several items to add to my cart, click next, enter my name, phone number and address, click next, enter the credit card number and click next, realise there is a typo in the Regex, click Stop, change one character and press F5 again ! aaaaaarrrrggghhh !
Unit Test Guy: Writes a 5 line unit test in half the time it takes Debugger guy to even reach the code, gets feedback in milliseconds, provides great documentation about what the regex is validating and ensures that changes to the code in the future do not invalidate the current requirements.
Essential reading: The Art of Unit Testing by Roy Osherove
My session on unit testing: Eat your vegetables! Baking Healthy Projects with Unit Testing and Dependency Injection
Common patterns like Repository and Unit of Work
Patterns are important.
They provide a way for developers to communicate about common problems and suggested solutions.
I hate to re-invent the wheel when smarter people have already come before me and done most of the heavy lifting.
Familiarity with common patterns (the good and the bad) is essential to any senior developer.
Clean Code & SOLID Principles
If software were disposable, I wouldn’t be writing this post.
If I could write software today, and then walk away and never have to look at it again I may not care about the day next year when I have to come back and make sense of it – but I do.
Because I have to maintain my code – I should very much care about making it easy to maintain. This is where the idea of ‘Clean Code’ and the SOLID Principles come in.
Essential reading: Clean Code by Robert Martin
Professional developers should be proud of the code they write.
I struggle to understand why most developers still don’t have a good understanding of the above topics. I strongly believe that these areas should be lived and breathed by every member of a development team.
Once again, you don’t have to always use them… but if you don’t have them in your tool-belt you’re selling yourself as a professional carpenter when you don’t even own a hammer.
I’ve deliberately left this until last.
Although most job descriptions are full of technologies, I believe that knowledge of the topics above are far more important.
Here is the current set of technologies that we use by default to build most of our web applications.
- Frameworks and Toolsets-> we like to keep across what’s out there, and being consultants doing new projects all the time we get to try out different things but our default stack at the moment is
- Twitter Bootstrap
- Telerik KendoUI
I deliver large, high performing web applications for enterprises. The processes, tools and technologies above are what I believe an enterprise web developer needs to know. Obviously other development disciplines require very different skills sets.
In many scenarios other tools, frameworks or methods may be more appropriate, but before you start learning all the alternatives you should know and understand the mainstream choice. Then you are qualified to have an opinion about whether something else is better.
The originators of Scrum, Ken Schwaber and Jeff Sutherland have released an updated version of the Scrum Guide.
Go here to get the latest version
Go here for their summary of the changes
Go here for a 17 min video of them discussing the changes.
Here are my key points taken from the video, and the summary page, and a few comments about them.
Interesting points on the uptake of Scrum
– two years ago the US Congress passed a law that all Department of Defence IT Projects must be agile
– this year.. the US embedded the Agile Manifesto in its government regulations
– The US post office has mandated Scrum everywhere in IT
– The Gartner group says ‘abandon waterfall.. get agile’
-Jim Johnson at the Stannis group repots: In a survey of 50-100,000 projects where success is defined as on time, on budget with happy customers (in itself a waterfall benchmark) –
The success rate in waterfall projects is 14%
The success in agile is 42% (Jeff believes this is not great.. but a conservative figure)
– The Forster report: next year there will be 3 trillion dollars spent on software
Ken: “our way of trying to narrow the gap between software that is needed and the available provisioning capacity is
– higher productivity
– higher value
– higher quality”
The 6 key changes to the 2013 Scrum Guide
1. Re-emphasising Transparency
A new section on Artefact Transparency has been added.
The key point made was that Ken and Jeff wanted to make it clear that if things are not visible to everyone, bad decisions can be made.
All of the Scrum artefacts should be transparent, and easily understood by everyone who is looking at them in order to maximise value and minimise risk.
2. Sprint Planning – One Section and a Sprint Goal
The sprint planning meeting is no longer divided into two sections.
The concept of the Sprint Goal was in the 2011 scrum guide, but it wasn’t clear enough and not enforced enough.
In the current edition, you must come out of sprint planning with a sprint goal.
The sprint goal should provide focus to the team.
3. Product Backlog – being ‘Ready’
The term ‘Grooming’ has been replaced with the term ‘Refinement’ (due to cultural sensitivity).
The ‘Ready’ state is being emphasised (as has previously been done with the ‘Done’ state)
Items that are ‘Ready’ are defined clearly enough and with enough detail to be able to be added to a sprint.
BEFORE the sprint planning meeting, PBIs that may be added to the sprint should be refined until they are ‘Ready’. This will accelerate the sprint planning meeting.
I think this is awesome. As a consultant, one of the issues I commonly find on Scrum teams is that the Sprint Planning meeting drags.
I always push back on Product Owners that if they want punchy Sprint Planning meetings, they should prioritise having a well groomed backlog with all of the BPIs likely to be included in the next sprint ready for estimation and inclusion.
4. Time Boxed Events
When you set the length of the sprint it does not change, but the meeting times specified are maximums.
(I don’t see this as a big change).
5. Daily Scrum – a Planning Event
The new guide reinforces the importance of the Daily Scrum as a PLANNING event, not just a status event.
It provides a great focus on each team member contributing and delivering value.
Ken: ‘It is about creating situations for the team to work together’
Every day the team should organise how they will work together to accomplish the sprint goal
The input to the meeting is how well the team is going.
The output from the meeting is a new or revised plan that optimises the teams efforts.
The three questions have been reformulated to emphasise the team over the individual.
a. What did I do yesterday that helped the Dev Team meet the Sprint Goal?
b. What will I do today to help the Dev Team meet the Sprint Goal?
c. Do I see any impediment that prevents me or the Dev Team from meeting the Sprint Goal ?
There is a greater focus on the sprint goal, rather than just on the status of what ‘I’ did.
Only tasks that contribute to the sprint goal are relevant.
A great example is given
– if a team member says ‘I spent the day writing this great report’ but the report does not contribute to the sprint goal
a. it should not have been included in the daily scrum (as it does not contribute to the sprint goal)
b. if they team member was busy, but did not contribute to the sprint goal, as far as the daily scrum is concerned… they did nothing
c. it could actually be considered an impediment as the team member is not focused on the sprint goal
6. Delivering Value
The concept of value is reinforced.
The product backlog should be prioritised by value.
At the end of the sprint review, one of the primary outputs should be a refined sprint backlog that will optimise the VALUE of the work the team is doing.
During the sprint review – the question is asked ‘based on what was done in the sprint what are the next things that could be done to optimise value ?’
The point is to maximise the value that the team delivers.
I say: Bravo !
Great quote: “We’ve got goals, we’ve got value, we’ve got transparency, we’ve got more teamwork ..it’s all good.”
The default Agile TFS template ships with three states: New, Active and Closed.
A common question that I am asked is how to add an extra stage to the TFS taskboard.
While this is not trivial in TFS 2012, it’s really not that hard once you know how, and is being made easier in newer versions of TFS.
Figure: We will demonstrate adding a ‘Testing’ column.
Step 1: Ensure that you are an administrator of the Team Project you are updating
Step 2: Download the Team Foundation Server 2012 Power Tools
– In Visual Studio select Tools, and then Extensions and Updates
Figure: Select Online from the left menu, enter Team Foundation 2012 in the search field, click the Download button on Microsoft Visual Studio Team Foundation Server 2012 Power Tools
Step 3: Export the Task Work Item Type
To add a new column to the task board, we need to add that status to the work item type definition.
Figure: From the Tools menu select, Process Editor, then Work Item Types and then Open WIT from Server
Figure: Expand the correct Team Project and select the Task work item type.
Step 4: Add the Testing state to the Task WIT
Figure: Select the Workflow tab. Open the toolbox and drag a State component onto the design surface. Right click on the new State, select Properties and set the Name property to Testing
Figure: Select the Transition Link component from the toolbox. Now click on the Active state and drag your mouse to the Testing state.
Figure: A transition will have been added from Active to Testing.
Figure: Right click on the Transition and choose Open Details. Go to the Reasons tab and Edit the reason value. Suggested test: ‘Ready for Testing’. You can click on the chevrons to expand the transition to be able to more clearly see the assigned properties.
Additional actions and Fields can also be specified but that is beyond the scope of this post.
Figure: Repeat the process above to add transitions from Testing to Complete (with a reason of ‘Testing Complete’) and from Testing back to Active (with a reason of ‘Failed Testing’).
Figure: Save the template to a known location on your hard drive so that it can be imported in the next step. E.g. c:\Temp\TeamProjectName_Task.wit
Step 5: Import the saved WIT
Figure: From the Tools menu select Process Editor, then Work Item Types and then Import WIT.
Figure: Browse to the location of the saved file, select the Team Project you wish to import the WIT into and click OK.
Figure: When you edit a task, the Testing status is now available. It is not yet however added to the board.
Step 6: Export the Process Template Config
This is the part that I always forget to do. After you have edited the Work Item Type, you still need to update the process template to include the State on the Task Board.
Figure: Open a command prompt, change to the Visual Studio IDE Folder and execute the following command
witadmin exportcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin exportcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”
Step 7: Edit the Process Template Config
Figure: Edit the exported file. Find the section for TaskWorkItems and add the line highlighted above.
<State type=”InProgress” value=”Testing” />
Save the file.
Step 8: Import the Process Template Config
Figure: Execute the following command
witadmin importcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin importcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”
Figure: View your task board and you will have your new column!
I had a conversation today with a lead developer who was working with a team who couldn’t get the hang of not checking in bad code. To resolve the issue, he implemented Gated Checkins. He asked me to check out some the code and I was happy to, right up until I had to do a few checkins. The following are my subsequent thoughts on the matter.
Gated checkins are used to stop developers from checking in bad code and breaking the build.
This does not contribute to high functioning teams, and instead masks, or even creates dysfunction.
To illustrate lets look at a couple of examples.
In the retro the team decides to turn gated checkins on because Jonny and Sue keep breaking the build.
The build doesn’t get broken any more, because Jonny and Sue now have to fix their code before they check it in.
This doesn’t mean that Jonny and Sue are writing better code, it just means that they are not checking in code that breaks the build.
Gated checkins will not improve their skill level, change their attitude or improve the quality of their code.
The development ninjas on the team are proud of their code, and check in several times per day.
Because the gated checkin takes 10 minutes their workflow is impacted.
They resent Jonny and Sue for having to work this way.
Gated Checkins mask the dysfunction on the team, and introduce impediments to the high performers.
Example – Gated Checkins mask dysfunction
In the retro the team discusses the fact that the build is often broken.
After a round table discussion about becoming better programmers and building better quality software, the team decides to the following guidelines:
1. The team will all run build notifications so that everyone knows when, and by whom the build is broken.
2. If someone needs help with solving a problem, they are going to feel good about asking for help early, and learning something new in the answer.
3. If someone is asked for help, they will gladly share their knowledge to ensure that the quality of the project is maintained ,and the team help each other to become better developers.
4. Before checking in, the devs will compile and run all tests. **
5. If someone checks in and does break the build, they will call out to all members of the team that the build is broken so that no-one gets latest. They will fix the build IMMEDIATELY, and then call out again when it is fixed.
(Some teams have a rule that if you break the build three times you have to shout coffee / lunch).
6. The team agrees that you don’t go home if the build isn’t green.
If it comes to the end of the day and you are not sure your code will not break the build – do not checkin. Create a shelveset and resolve the issue properly the next day.
If you have checked in, the build is broken, and you cannot fix it before going home, you must email all devs on the team, and the product owner with an explanation.
7. The status of the build is reviewed in every daily scrum. Edit: Gerard correctly pointed out that this is bad Scrum.
Example – The whole team should be constantly aware and invested in the status of the build, the quality of the software and in encouraging each other to better developers.
** I actually don’t follow this rule when working on small teams of awesome devs, who write code against tests and checkin frequently.
Instead I encourage the process to be
– checkin 4-5 times a day
– write lots of tests
– if the tests that you are working against pass- checkin and let the build server do a full compile and run all the tests
– if you have broken the build, call it out, fix it immediately and then call it out again.
This is the most productive way for small teams of awesome developers to produce great code… and it’s fun !
Day 2 begins
Bonus 1: Today, we made it to the training venue in only 3 minutes vs. 1.5 hours yesterday. Talk about continuous improvement!
Today’s agenda saw a lot more interaction with the lovely Team Foundation Server (TFS). It was time to see Scrum in action with the Microsoft tools.
Impediment 1: Matthew Hodgkins spent some time setting up laptop for us to bring along to the course. It was set up with domain server and a TFS Virtual Machine ready for all the students to connect to. We were expecting a room full of cables to a switch, but unfortunately the training venue only had wireless. There was no way for students to connect!
Bonus 1: With a lot of help from Matthew and Parmod Kumar (one of the Sysadmins working with the students), we got the server reconfigured so everyone could connect!
Work Items in TFS
Adam C started the day by cracking open TFS and walking through the work item world:
- Creating a Team Project
- Team Collections
- Areas and Iterations
- Managing Sprint Work Items
- Creating some Product Backlog Items
- Creating and Linking a Task
- Creating and Linking a Test Case
- Creating and Linking a Bug
- Managing Impediments
- Adding Check-in Policies
Adam professed his love for Story Overview reports and also Priyanka Chopra. He also spoke about his “tough” guts and what a “handbreak” Damian and I were for not eating street food with him.
He let the teams have a quick break while he introduced them an awesome tool called Debugger Canvas.
Then it was on to TFS integration with Microsoft Excel and Project 2010, TeamCompanion, and UrbanTurtle.
Adam introduced the first sprint of the day by telling everyone that there was a new Product Owner. He talked about all the things this new PO might want, so they would be well prepared when he arrived.
A new Product Owner arrives
This new Product Owner was a bit odd. He talked about his new wife, the new Tailspin website he purchased, and the Chinese developers he had sacked. He told them about the bugs some people had told him about, and asked them to:
- Connect to TFS
- Log in to the SQL database
- Create a Team Project
- Add the 2 check-in policies he had heard about at a Microsoft seminar (being the “comments one in the Powertools”, and the “work items one that comes out of the box”)
- Check that the code from the Chinese developers compiles
- Tell him where he stands, and whether those Chinese guys were truthful when they told him it was “99% done”
The students had been given so much new information that morning, we were interested to know what they actually “heard”.
All of the teams did OK considering this was their very first technical presentation. We all know the human brain starts working when you’re born, and doesn’t stop until you stand up to speak in public.
Interestingly, they were very keen to show the Product Owner *all* of the work items they had created. They had a very different idea of what they had to do.
There were a few impediments this time, however. The teams found that they needed to install TFS Powertools in order to add the Check-in Policies. Due to frequent power outages (apparently rampant in summer), this seemed to cause a lot of problems. “Team Masters” had even added an impediment to TFS saying that TFS was down and was blocking them! The Product Owner looked at them very incredulously.
“Team Scrumsters” actually fired up the new application and showed it working. They were the only team that got the Product Owner jumping up and down with excitement.
Before the Product Owner left, he played a video to introduce the students to some of his “American culture”. He played a Charlie Sheen video and talked about the importance of “winning”.
The big lesson that came out of the acceptance criteria was that the teams didn’t clearly understand what the Product Owner wanted. Every team had a very different idea of what was required:
Once again, lunch was delicious. I asked heaps of questions about the selection of traditional Indian foods, the answers being fascinating. I’m well and truly on track to come home with some new recipes!
After lunch, Adam C treated the group to some Australian culture in the form of an ad for Fosters. He followed this up with a (remarkably similar) Canadian Molson video and was disappointed when the group preferred the Canadian version!
During lunch, Pradeep requested they see how the Aussies do their planning and standup meetings.
Adam C asked Damian and I to stand up in front of the class and start work on a new sprint.
- We started with the creation of a backlog, estimated tasks (with their fists), and created a burndown
- We started and finished day one, and just as we finished,
- Adam got us to do a day 2 standup, complete with a burndown update
Bonus 2: This ended up being quite worthwhile. Some of the students said it was the highlight as they got to see how it was “meant” to be done.
Adam C played the students a Karate Kid video to highlight the point that following the Scrum process is like developing muscle memory. If you follow the process, it starts to become second nature and you reap the benefits.
Sprint 2 saw the teams get deeper into the solution. They were asked to enter some more Product Backlog Items and make sure each person raised a bug.
Bonus 3: This sprint, every one of the teams did a standup and one team implemented the “fist” estimation technique.
The Review and Retrospective meetings were are lot more impressive this time. All teams did a great job with their presentation and the Scrum process was finally in action in all its glory.
To close off the day, Adam C played a video showing how Emperor penguins work as a team for survival in Antarctica. He emphasised the importance on the team in the Scrum framework. If everyone is prepared to give their bit for the team, it will benefit everyone.
Retrospective Day 2
There was a lot of great feedback from the students on how the day went. Some of the many highlights the group mentioned were:
- Learning to focus on what the Product Owner wants, not the process
- Seeing the tool (TFS) was much different to just knowing the theory
- The demo of the “Aussie” planning and standup meetings
- The Karate Kid story – the group now knows this is something to follow day in and day out
- Learning what Scrum terms map to what TFS work items
- The Excel and TeamCompanion demos
- Working as a team
- Doing the exercises
- Learning about Check-in Policies
- Moving from theory to practical implementation
- The story of the Antarctic penguins and the importance of working in a good team
Tomorrow will see us delve deeper into Scrum using TFS and we’ll look at using Microsoft Test Manager to help run tests and raise very rich and repeatable bugs.
I’m in India at the moment with Adam Cogan and Damian Brady helping out on a Professional Scrum Developer course. The training is with a group of 24 guys with varying roles – developers, testers, architects, and managers. At the end of the course, they will all have the opportunity to sit an online exam to become “Professional Scrum Developers”.
It was such a fun day, we decided to sit down and write a blog post together.
We decided to catch a couple of tuk-tuks to the venue. Adam C somehow managed to send emails on his iPad while cramped in the back.
One of the important things you learn about in Scrum is an Impediment. Even before day 1 started, we had our first one.
Impediment 1: The distance from our hotel to the training venue was about 2km. The 1.5 hour journey (yes, one and a half hours) to this venue on the first day included three lost taxis (two independently finding their way to the same wrong address) and several near-death experiences.
Tip: Don’t think about complaining to your tuk-tuk driver or else you will find him try to make you happy by driving the wrong way down a busy main road.
Getting Started with “Scrumdementals”
Impediment 2: Day 1 officially started with Adam noticing that only one of the 24 students had read the Scrum guide. To bring everyone up to speed, he was able to give a succinct rundown of the Scrum user guide with the help of a few SSW rules (The importance of a team, Reading the Scrum Guide, and Physical Task Boards) and the awesome “Scrum Master in Under 10 Minutes” video by Hameed Shojaee.
The “guts” of Scrum was covered, with particular reference to short iterations, multi-skilled teams and timeboxing. Adam C also told a story about his years in the army, and pressed the point about the “inspect and adapt” tenet of Scrum which got a laugh. The army tends to plan a mission, watch it all go very differently, and then debrief so they can adapt.
Adam C talked about the burndown and asked which time fields in a User Story mattered for the burndown. Two of the 24 students already knew that the only time field that Scrum cares about is the “remaining time”. Adam went on to explain why this was, and why the “original estimate” and “actual time” spent fields aren’t as important.
After a morning break, Adam C spoke to the group about User Stories. Everybody loved his quintessential example with accompanying story:
As a marketing manager
I want to search for customers
So that I can call them up
He followed this up with a discussion about Acceptance Criteria and why they were so important. Referencing the SSW rule on Acceptance Criteria, (one of my favourites – I wrote it) it was pointed out that you should never assume “gold plating” for a User Story. The group appreciated the clarification on acceptance criteria and agreed that it was important for clarity.
Adam C’s next instruction was for each student to write one of their current working items in the form of a SSW story card. Some were good, and some were not so good. Damian reviewed his favourite ones to the class.
After lunch, the group was asked to self-organise into four teams of six. Initially, the groupings weren’t ideal (all the developers with MVC experience were in the same team), maybe the ‘multi-skilled’ point was forgotten… a quick bit of shuffling was required.
Bonus 1: Even though team members were being split up, the new teams worked really well together.
Next, the Product Owner entered the room and scared everyone with his tough requirements. He is a Product Owner you don’t want to mess with.
He spent 10 minutes (timeboxed) giving out requirements for the first one hour sprint. The task was to create a poster for his boardroom. The sprint was split into four 15min “days”, after which the teams presented the results in the review meeting.
Impediment 3: Every half hour or so, a “black room event” occurred. No, not a “black swan event” :-). Apparently power outages are fairly common in Delhi, but every time it happened, the laptops switched to battery and all network connections were lost.
The post-sprint Review meetings were fun with the teams presenting some different results in their work. The Product Owner was hard to please, but we think under that tough skin, he was generally pleased with the work. The same can’t be said about the process. In the end, he chose his favourite diagram to hang on his boardroom wall.
The Retrospective meeting was even more fun and the teams learnt some very valuable lessons. However, Adam C explained that every one of the the teams was naughty:
- Only 1 of 4 teams took up the invitation to speak to the Product Owner about what he wanted
- 2 teams did a User Story for the task (despite Adam C giving several “Printed Story Cards” to each team)
- None of the teams kept a Backlog
- None of the teams did a Daily Standup, and
- Only 2 teams followed the brief and included pretty pictures (this was very important to the Product Owner)
Later on, Adam C presented his ideal Scrum diagram and spoke about how it clearly shows the Scrum process from start to finish.
The day ended with a retrospective where each student talked about what they liked and disliked about the day.
The top two highlights of the day – repeated multiple times – were:
- Writing User Stories and learning about why the wording was important
- Learning about effective acceptance criteria
The students said they were very happy with the course so far. They wanted 2 things improved for the next day:
- There weren’t enough videos (we’ll fix that on day 2!)
- Lunch was too early
Can’t wait for Day 2.