Jim starts by talking about the two computing eras in the last 20 years, and then branches into the 2010’s era:
- 1990’s - Store and compute
- 2000’s - Search and browse
- 2010’s - Know and do
He then continued referring to the “Old magic” with the “New magic”. I don’t need to go into the old magic because we have all lived it – but he says cool things about the new magic. It’s going to be based on new radical ways of interacting with your digital world.
Know and do
This era will be based on three things:
- Data – not the web, but your own index to the web
- Experiences – “takes the data and weaves into cool things”
- Ecosystem – Cloud and devices
Whittaker talks about the paradigm switch from generic search to specific “experiences” tied to local knowledge of data, that is, not the web but the personal indexes to the web based on how we interact with it: location, timing, history. Underlying it of course is that “Data is currency”. This all leads to “experiences” in the sense that the data needs to be harvested by app developers with data owners, at a local basis, to design those experiences.
Data is tied to experiences which are tied to data gathering/harvesting to something that is the data ecosystem: clouds and devices. Most experiences are drawn in “canvasses”: space and time. Most experiences can be mapped to both spatial and temporal a relationship, that is canvasses for the experiences to unfold. Example of an experience:
“I need a vacation”. Where would such experience start? Maybe in the calendar, and it does not need to leave there. Whittaker then went into a lot of interesting scenarios such as “Decline all my meetings and show me some flights”. After this your calendar would show flights in the calendar, and as you choose one, then screen changes with suggestions for hotels and discounts – all in the calendar. Plus it shows some recommended activities that you can just pick and have them neatly fit into the calendar. It ends with a nice one-week calendar with a vacation created from an auction system for the best experiences you might want to live.
As a new era starts, Whittaker explained that it becomes difficult for the incumbents. We just started, so the winner is still not know, and he invites us to join in developing new experiences in this new paradigm.
Peter’s presentation was to me a direct segue from my observations on Leffingwell’s presentation. It was about make programming fun again, to motivate people so they get to that next level where you are looking forward to Monday, to delight your colleagues with the best you can do, where colleagues are friends, where you work hard and play hard. “Have fun!”
His argument is that we need to focus on the long game but not forget the short game.
“Just in time planning, definition, estimation and design are good but people need to understand the roadmap”
So when teams don’t see the long picture teams will be make decisions to account for this uncertainty. That reminded me of “shared vision” that Jim McCarthy talked about: with it you can make short term decisions and align yourself with the long term, have a north to your compass.
Add a personal perspective that gets you excited about “changing the world”. That brings me a reflection on being part of a team, an organization, which provides value to society. Are we helping people be happier, better themselves?
“Tools are important, but not the most important.”
I talked at length about this on my talk at Scrum.org Face to Face, and it seems to be a recurring theme on this ALM Summit. We concurred that “peoples and interactions” are the substance of bringing motivation back to the team. “Tools should be supportive to the process”. If the tool gets in the way, if it brings you pain, if it takes fun of what you are doing then there is something wrong (for those in the Pulse team: Peter is a program manager in Visual Studio/TFS – feel free to send me a summary of your pain, and I will send it to him).
Peter then moved to talking about “Simplicity doesn’t mean stupid”:
“Just Barely Good Enough==the most effective possible
Apply this rule to everything in your project, team, tools & artifacts”
This point by Scott Ambler is better understood by looking at the following diagram:
Listening to Peter talk about this is very convincing about the value of this principle – however, I also respect Rebecca Wirfs-Brock as one of the pioneers of Agile, when Agile was not even called that – and she argues the opposite: http://wirfs-brock.com/blog/2006/09/29/barely-good-enough-doesnt-cut-it/. I will need to think more about this one.
“Beware Unintended Consequences – your team will react to anything that hurts or scares them”
As an example he mentions the expression “don’t break the build!” – developers will react to that (“no one wants to have a toilet seat or crocodile doll in your office ” by imposing restrictions on themselves (check-in less frequently, check-in bigger chunks, which lead to big merges). It should have been stated “You broke the build? OK, but fix it immediately”. Why the short phrase? Because the earlier statement was just too big, “Don’t break the build” is easier to remember. And scare. Another classical example of this are metrics – use them wisely and for your own understanding, because the moment you try to drive motivation based on metrics the team will contort their behaviors to satisfy those instead of focusing of having pleasure from shipping something new.
Well my take on his idea is to think about what the unintended consequences of rules. If they bring the team down, then recognize, think about them, and change them – don’t let them spoil the team motivation because of tradition and legacy imposed on you.
Then Peter talked about Dan Pink’s ideas about motivation, which he summarized as:
· Autonomy – Empower and trust people to make decisions
· Mastery – Give your team members the opportunity to improve and grow their craft
· Purpose – Show them the big picture and their place in it
Funny is that Eric Weber had talked about the same ideas in his presentation (“Scrum and Drive”) during the Scrum Face to Face meeting. And it seems a running theme across the minds of Agile thinkers.
Finally he talked about “Outcomes are more important than processes”. What I understood from this is that at the end of the day, we should think of ourselves not as “cost centers” (especially if you are in IT) but as “business differentiators, as contributors”. It is not nice to be considered from the outset as a burden. Motivation goes down from there. Why stick with this tradition dictated by process when what matters is to motivate people to the next level of excellence?
Sean Laberee (lead program manager on SharePoint and office development tools) started by describing the impression that most people have of the current state of the art of SharePoint development by asking: what do these have in common?
- Dentist visit
- Public speaking
- SharePoint development
So the purpose of his talk is to show that SharePoint development has become Agile, and most of the pain/panic associated with it can go away.
The main topics were the following:
- A nice way to find relatively cheap business apps for common needs
- Nice sandbox app isolation – apps from store can’t take over SharePoint data without explicit permission
Better App Management
- Nice interface to manage app licenses
- Both a catalogue and license manager
- Able to configure a developer box in no less than 5 hours before, now it takes 15 minutes
- Microsoft NAPA is a SharePoint app for development that does not need SharePoint – you can start in Office 365 and develop for 365
New Cloud App model
- provides a simpler, neat model for app development (Office and SharePoint)
- SharePoint app dev now seamless look like normal web development
- See more comments below on options for hosting
Continuous Integration Improvements
SharePoint app hosting options:
- Supported on premises and on office 365
- Most flexible if you don’t need server code
- New Azure website and SQL Azure DB per app instance
- Best suited for store apps for office 365
- Use any provider to host your web server
- Support on premises and on office 365
- One server supports all instances of the app
He finalized by mentioning that this talk is about making SharePoint more like normal web development – that’s why not much of SharePoint was shown in the presentation. I agree: it looked a lot more Agile in the sense that it flowed naturally, no snags/impediments that normally come from infrastructure. I will finally go back to the dentist, err, SharePoint development in the near future.
Leffingwell’s presentation was on Scaled Agile Framework (SAFE), and an explanation on Lean applied to software development. He showed how Scrum fits neatly with Lean principles:
“Scrum is founded on Lean
- Cross functional teams
- Time boxes to limit WIP
- Sprints provide fast feedback
- Empowered, local decision making
- ·Colocation reduces batch sized and communication overhead
XP is quintessentially Lean [etc]”
Also while talking about applying WIP constraints he mentioned the following:
“Timeboxes prevent uncontrolled expansion of work making wait times predictable.”
This to me resolves one of those artificial conflicts between Scrum and Lean/Kanban: that timeboxes are not useful anymore. Leffingwell provides a very fresh view on a subject that tends to get polarized once in a while.
However I am still pondering if ideas that have origin in manufacturing are fully applicable to an intellectual endeavor such as software development. To me the bottleneck is managing creative people so as to raise in them the motivation to do their best work, and excellence follows naturally. Lean seems to me (at this point of my research) more on the side of getting out of the way the hurdles caused by administrators that imagine that they can manage developers as they manage robots in a factory floor. Queuing theory understanding helps alleviate the burden caused by managers that want to over-optimize the external measures of efficiency, such as hours, backlog size, etc., that is, physical coordination.
Don’t get me wrong, this is useful to put some restraints on the “Office Space” manager kind. However, the effect on motivation is just to free up the mind of the developer so they can have the ideal proposed by Kent Beck as the “40-hour work week”, that is, the effect to me is essentially cleaning up the road. The road trip has yet to be done.
I was listening again to Jim McCarthy’s presentation on how he achieved a “shared mindset” with the Visual Studio team. That was real motivation, the kind that can make a developer, who is just doing their minimum to get-by until he finds something better, into someone who can be ten times more productive only because now he is motivated to do so. This is the kind of productivity management the software industry needs today, and will always need.
The Scrum.org Face to Face meeting this weekend (Jan. 26-27) was as usual packed with information I will be digesting over the next few weeks. Here is a list of the sessions we had, all provided by the Professional Scrum trainers present at the meeting:
- Simon Reindl - Scaling Scrum using TFS 2012
- Todd Greene - Standing on the pillars of Empiricism in Hostile Waters
- Gary Pedretti - Using the PSD as a Springboard to Teach Cross-Functional Team Behavior
- Ken Schwaber - The State of Scrum - A discussion of news, events, and developments in the broader Scrum community. This includes topics of general interest to Scrum experts.
- Alexandre Mac Fadden – Agile Estimation
- Jeff Hunsaker - Measuring Agile Success – Providing Proof
- David Starr – Fine tuning feature/increment relationship for release planning
- Charles Bradley - Help a PST Newbie
- Clementino Mendonca - Method drives tool: Enacting Agile/Scrum in ALM tools
- Stacy Martin - The Impact of Expedient Team Storming
- Richard Hundhausen - PSD .NET Retraining
- Victor Hugo de Oliveira - Developer Training Approach - Going Undercover
- Erik Weber - Scrum and Drive
- Scott Anderson – Business Analysts vs. Product Owners – striking a balance in the team
- Chad Albrecht - The Agile Development Trinity
So those are not the typical meetings where you just sit in the back and passively watch: in a Scrum Face to Face we are all invited to actively participate. With every presentation it transpired the ideal of contributing to the “improvement of the profession of software development” .
A couple of highlights:
Ken Schwaber, one of the creators of Scrum, presented on the current state of things. Scrum.org is now working on CIF (Continuous Improvement Framework) to help companies establish an ongoing improvement cycle by getting a baseline understanding of where they are in relation to other companies, then drilling down on the sweet spots for Scrum practices adoption.
Richard Hundhausen worked with us through the latest version of the Professional Scrum Developer course. There are great improvements to the content, and reading it by itself is already very enriching.
The PDF for the course will be made available to the public, but to get the most value out of it the best is to attend a course with a Professional Scrum Developer Trainer. That’s when you get the experience of going through 5 sprints and a real scenario of software development, not just the fake “game experiences” you usually get from Agile/Scrum course.
Not that you don’t get value out of those, what I mean is that with the course you get the real feeling of being part of a development team that is readily applicable to your life the next day after the course, no need for translations from the game world to the real world.
Finally, in my session I presented on “Method drives tool: Enacting Agile/Scrum in ALM tools” where I talked about the fact that a lot of tool “marketecture” going around has been usually claiming great savings, cycle time reductions or benefits from adopting this or that tool/tool feature. In reality most benefit is coming from changing the way the team works, that is, by adopting an Agile method such as Scrum.
The tool automation/enactment add-on benefits come on top of those. In my experience they are in the order of about 10 to 20% of overall improvement, and that 80% comes from just changing the way that the team works – even if you keep the same tools. Some tools such as TFS provide Agile practices “canned” into them (and therefore claim those savings) just by the way they work out of the box, which by default change the way a team operates.
However if there is not a conscious understanding that the process is also changing, it leads to friction as old habits get in the way and drive down those savings/benefits/cycle time reductions, which get relegated to a few workflows while overall the team continues to operate in a waterfall manner.
As I go back to think again on each presentation – they were so rich – I will be sharing my thoughts on the topics as well. It will most likely be after the ALM Summit starting today.