Angular 2 - useful links

Angular 2 is a release candidate: rc.1 as I write this.  The official documents still have some missing pieces.  Here are a collection of useful links and my own usage comments to help fill in the missing bits:

Official Docs

Official latest Angular 2 docs - fairly good. Some bits missing as of rc.1

Official TypeScript docs - very good - starts with basic types selected

Unit Testing

Unit Testing Recipes - useful recipes for testing Components, Directives, HTTP Mocking etc - though think this conflicts with the latest I've found on async injecting into unit tests.  I might be wrong.

Testing Angular 2 Components with Unit Tests and the TestComponentBuilder (RC1+) - -but see this repo for tests actually updated for RC1:    --- note that TestComponentBuilder has been moved from @angular/core/testing to @angular/compiler/testing.

Touch events

Haven't tried this yet -- not sure what really works. It does seem that Hammer.js must be loaded before angular2.

Bootstrap Carousel

..I'll add more as I revisit links.. First week or two with Angular 2 involved a lot of reading source and searching for solutions..

The five deep themes in Scrum

Scrum is a reasonably human-friendly process for developing products.  It seems a lot nicer and more effective than waterfall and other traditional project management.  But what is actually going on in Scrum?  Apart from attending a bunch of ritualised meetings, what is going on for individuals in the process?

Here are the five deeper themes I like to work with.  I find that keeping these in mind and using them as a lens to view team behaviour and progress really helps identifying blockages and improvements:

1. Rhythm

Scrum brings the rhythm of the Sprint (typically 2-4 weeks) and the Daily Scrum or standup.  These rituals repeat, marking beginnings and endings for the team. There are lots of beginnings and endings, so very different to a single 'delivery date' that the team might get in a traditional project.  Regular beginnings and endings make it easier to make process changes and see changes happening.

2. Narrative

The Daily Scrum requires a team member to speak about their work since the last one; to form a narrative; a story for themselves.   The narrative is witnessed by others in the team.  This helps the individual make sense of what they are doing -- to make and adjust and reflect on the story.    Similarly, a review and retrospective gives the team as a whole a way of making and processing the narrative of the last Sprint.  They have a story for how it was.

3. Reflective Practice

Making a narrative and a regular rhythm opens up the possibility of Reflective Practice.  Reflective practice is the process of reflecting on events and actions to allow continuous learning and growing.  The team can do this regularly within Sprint Retrospectives.  Identifying changes; trying them out; witnessing and reflecting on the results.    This is where the team and individuals can grow out of their normal roles.

4. Ownership

The team estimates the work and decided on how much they will take on as a part of Sprint Planning.  This gives the team ownership of their own work, setting up responsibility, bonding the team on a shared purpose shared control over what they do.  This greatly helps to generate ownership and responsibility for the product they are delivering.

This is not automatic. As a Scrum Master, I have to be aware of this during Sprint Planning, make the space and allow the team to take ownership.

5. Direction and Purpose

A well-defined Product Backlog and a stable current Sprint gives the team a direction and purpose. This is context setting for current work and builds a stable base.  We want team members to be both diligent and innovative; they needs a stable world to work within.

Careful planning and an accessible and decisive Product Owner allows the team to plan for current reality and quickly resolve any hanging uncertainties that undermine purpose and direction.

Which agile tracking tool?

This is a pretty common question:  What tool should I use for tracking my Agile project or Sprint?  

In my humble opinion, based on what I've been using recently:

If you want a simple display for a few tasks with easy setup and easy start, go with Trello.  This is really a visual card column system, Kanban style.  It is beautifully ad-hoc, and you get a good usable tool quickly.  Create a board, add some columns, add some cards.  As easy as that.   I find the limits come when you can't fit all the cards on the screen.  It also does collaboration surprisingly well.  A favourite quick planning tool.

If you're looking for something that definitely pushes you into thinking in Scrum-like Sprints, I'd go with Pivotal Tracker.  It has opinions about how you'll plan and work.  It organises sprints for you, helps you build and manage a backlog easily.  I  like this and use it for a lot of my personal and small projects. Pivotal manages sprints and velocity fairly seamlessly and otherwise stays out of the way. 

If you've got time for configuration and are on the bigger project side of things, I'd take a look at Atlassian Jira Agile.  You get something that is more like a issue tracking system with reasonable add-ons for agile processes.  It works well when configured.  You will spend configuration time.

And if none of these sound like you: start with an on-line collaborative spreadsheet (e.g. Google Sheets) and use that.  If the point is to plan and communicate, you can go a long way with a single spreadsheet with a few tabs. 

There are a lot of tools in this space.  Ask Google if you want to go deeper.

Or give me a shout and I can chuck in some more ideas.

Scrum retrospectives: what is going on, how to make them work

Scrum is a beautiful thing.  We carve out a corner of the business-as-usual world and change the values and working ways.  We do this because it is one way we can get a product built in the chaos of modern corporate life without sacrificing people, a ton of money and the quality of the product.  

And I’d say the Sprint Retrospective, and what follows from it, is the most beautiful part of all.  Enshrined in the process, every two or four weeks, we pause for a moment and look at how the last sprint went. We’re looking at our conditions. Our scrum.  Our process.  And then we look at how we can improve them, and make a plan to make some improvements over the next Sprint.

This is reflective practice, done as a team, regularly.   And this is really important.  With a reflective practice, the team and team members are able to learn, grow skills and develop.    There are opportunities for people to try something different, design a part of the process, step up to something, and be witnessed doing it by the team.

In this way, the sprint becomes a place for learning and experimentation, for growing skills and virtues in the team members.

So what does this mean for running end-of-sprint retrospectives?  Here are some reflection points I use before beginning a retrospective:

1. The retrospective is a way for us to improve our ways of working, contentment and conditions.  It is important for team morale and for individual’s growth.

2. As a scrum master, I'm looking to embed a culture of continuous improvement via the sprintly reflective practice and doing work in the Sprint.  

3. Key messages for scrum master and team going into a retrospective:

  • The team has the power to improve their conditions (improve their processes and work lives, deliver more points, improve quality).
  • Team morale comes from delivering points and working on improving conditions. Both are important. Skipping either will lead to trouble.
  • Blaming others is not going to work.  Striving to understand them is a beginning.
  • When evaluating the results of changes made from retrospectives:

4. When working on improving conditions, failure is totally OK.  Focus on the learning from what happened.  This is a kind of gentle inquiry into what happened.  Hold it lightly.  We’re looking for this kind of feeling:  “[laughs]. Wow I really screwed that up [laughs and smiles]. I wonder why?”.

5. Blame destroys the learning.  Work away from “They screwed it up!” to a gentle inquiry into what happened and why.  Understanding the context of the world/business we are in helps us work out what to do.

6. Witnessing is important. Team members need to witness each others successes and failures, doubts and concerns.  Therefore the importance of showcasing both functional work and retrospective-driven improvements.

7. Sometimes, a team is too burned or shocked or harried to be able to get in a place to run a retrospective.   It is important to notice these times.  Rather than push it, here is an opportunity for some time out.  Ideally use this time to go out for a walk.  Nature helps if available. Get out of the office and just walk for a bit.  People will chat amongst each other.  I don't feel any need to structure this, it seems like people chit chat, work and team issues come up and are discussed and put away again.   A camp fire would probably work even better, but that is harder to organise in the daytime in most urban areas :-)

8. As a leader, show your weakness, acknowledge your screwups, and showcase your learning with the team.

OK, that is pretty dense.  That is definitely enough to think about. Distilled to one key point:

  • Cultivate a gentle, inquisitive, reflective learning amongst the team and yourself. Hold it all lightly. Laugh, but with kindness.  Keep the rhythm.

Domain shennanigans

We've had a DNS provider and registrar account hacked, so the older familiar domain is currently out of our control.  

So, in the meantime (and going forward as well) we're moving to as the primary nodestone domain for emails and all that.  The .com will come back into use sometime soon.