Team coach and full stack developer.
Team coach and full stack developer.
You have a team member who has a pressing issue. It’s the single most important thing that they need to resolve. They explain the problem to a coworker, suggest a solution and ask for support… and all they get is a tepid response. This is a situation that repeats itself across workplaces every day. There are many reasons why people refrain from helping. They might not have the competence, they might disagree with the solution/problem or maybe they just don’t have the time. But what happens when they have the competence, agree with the assessment and could easily make time, but choose not to? Why don’t they? How do you help your team navigate these situations?
As a high-performing tech professional, it’s useful to constantly fine-tune your ability to add value.
For example, you might ask yourself at work:
What is the one thing we can change in our product, service or in the way we work together that can bring more value to our customers or the team?
This philosophy of looking for things that can add value can also be used for your personal and professional development.
To give you some inspiration, here are some of the real life small changes and habits that our team members at Crisp have made that have added tremendous value to our personal and work lives. read more »
You have probably read about “at scale” implementations, activity based offices, globally distributed teams, SAFe, Agile transformations and outsourcing. Beware. Danger can be lurking beneath the surface of these popular phenomena.
When the BBC published their “No CEO” piece where Crisp is featured with an article and a 4 minute video, there were a lot of reactions. Friends cheered on Facebook. Colleagues gave a thumbs up on LinkedIn. The article was featured on Hacker News and Slashdot. Here are our reflections on some of the comments we found.
Start out with all your potential solutions for a feature idea. Next, filter based on how the solutions perform using a set of verification methods. Finally, implement the feature knowing that you’ve found the solution that meets your needs.
The following are the verification methods I’ve experienced most often on the projects: read more »
Conflicts in teams about how to work are common. There are expectations from team members on each other that aren’t being met. In a given team, members might be implicitly expected to perform a certain task. The team might have unspoken policies that seem to be common sense. Sometimes people pick up on these unspoken rules and implicit expectations, but when they don’t, you have a team in conflict. You can’t avoid all conflict (and a dose of healthy debate and discussion is good for teams), but you can help teams by explicitly defining the roles and working agreements. Instead of dealing with conflict after the fact, you start with discussion and agreement. The following workshop is the one I use with my teams and organizations.
I gave a lightning talk at tonight’s Lean Tribe Gathering in Stockholm about A/B testing at King, how we develop games, features and decide which improvements to make. Here are my slides and notes from the presentation.
Candy Crush Soda releases a new version of the game on all platforms every other week, year round. I’ve written about the delivery pipeline and the challenges the team faces on King’s tech blog: https://techblog.king.com/candy-crush-soda-saga-delivery-pipeline/
I’m currently coaching a team with several stakeholders in different parts of the organization. It’s difficult to know who to talk to when decisions need to be made. The line between what the team can decide about and what the stakeholders need to be involved in is also blurry. To help create more clarity and a better collaborative environment with our stakeholders we decided to create a delegation board. The meetings we ran this week were appreciated by everybody, so I thought I would share what we did and what we learned.
Daniel and Martin have been in the same team since the beginning of summer and they’ve been collaborating in an unconventional way. Yassal interviews them to understand what’s been going on.
You’ve been successfully using mob programming with your team at Expressen for the past 6 months. How did you get started?
Daniel: The project started without any tech solutions in mind. We decided as a team that mob programming was a good way to figure out what tech stack to use. We had no backlog, but we sort of knew what we needed to do
Martin: I remember proposing this as the best way to do discovery work from a tech perspective. We didn’t know what language or tech platform we were aiming for, and this way we would learn more quickly as a team and could come to a decision.
So, what is mob programming anyway?
Daniel: I don’t really care about the formal definition, to me it’s group programming rather than pair programming. One person is at the keyboard and the others act as support, coming up with suggestions, or researching potential solutions. This helps the whole team stay on the same page, and makes sure that we’re all learning at the same pace.
Our goal at the Crisp hack summit last weekend was to migrate our 2 year old shopping app written in Meteor to the latest version and to learn about Google’s material design. Our old app was built as a way for us to learn Meteor. The structure is less than ideal, and as we learn new things we add them to the app, but don’t revisit old parts. So we followed Dan North’s experiment rewriting the app from scratch. We also decided to use Materialize for the UI. We wanted to rewrite the app in 2 days, keeping all the functionality we currently have, but at the same time adding the UI and usability improvements that we really need.
We ended up completing the rewrite in 9 days: 2 hack days and then a couple of hours each day for the next week. Not too bad for a brand new app, but surprisingly longer than we would have guessed. Both Meteor and Materialize are pretty simple to get started with, but adding Materialize to Meteor proved to be challenging. Here are some highlights!
How do you decide what to build next? Who comes up with the ideas? How do you decide in what order to implement them? How do you keep track of what you’re working on, and what you want to work on?
Here’s a behind the scenes look at how the Candy Crush Soda team comes up with ideas and decides what to build next!
Curious about how we developed Candy Crush Soda at King? Like any project we’ve had our challenges. We developed the game on a framework that had never been tested live, while programming in two languages simultaneously to support multiple operating systems. Adding to the challenge, we started working without a prototyped game idea, within an existing Saga format that comes with a long list of features that players are used to. The project, code-named Stritz, was born in the spring of 2013. We soft launched a year later, and hard launched in the fall of 2014. This is our story.
At my current project we use a Google spreadsheet to manage our backlogs. This works really well for storing and sharing the backlog, but it’s not very good for visualizing it. So we print out the stories on cards by copying and pasting each row into a document table cell and reformatting, adding extra labels, and manually inserting priority. Well, that’s what we did the first couple of times, until I found David Vujic’s fantastic Index Card Generator for Google spreadsheets (http://davidvujic.blogspot.se/2011/06/visa-vad-du-gor-eller-dude-wheres-my.html).
Except, we have multiple backlogs in one sheet, our column names aren’t the same, and we use a different layout for the cards. Here’s how we customized David’s script! read more »
Here are the slides from my lightning talk at Crisp today on Continuous Delivery!
There are no standard plugins for Grunt in Gradle, but it’s easy to add all the code manually. After all, this is Gradle not Maven 😉
Have you ever been part of a great team? Or worked with one? I’m ending an assignment at Projectplace, where I’ve been working with team “SNAP”. SNAP is a great team! As I move on to other challenges I’ve been thinking about what makes a team great.
Jez Humble posted a blog entry with the same title in 2010, but if you haven’t read the entry, or just want a quick explanation, here’s the short version:
A continuous delivery pipeline automatically tests the application, but keeps the deployment decision as a manual step. A continuous deployment pipeline, on the other hand, will automatically deploy this working version. There is no “right” way. Different organizations have different needs. Use the one that delivers the most value to your customers!
Continuous delivery is a hot topic. A lot of people are talking about it, but implementation in the real world is scarce. I lucked out at my last assignment when I was at SVT (Swedish Public Television) and got the chance to work on implementing a continuous delivery pipeline.
When I started, the project had delivered once and was gearing up for its second delivery. Representatives from each team met, and we decided to aim for an (at the time) aggressive schedule of one release per week! Our first “fast” release would go out in January, and we would continue from there.
It would be nice to say that this worked out well and we were continuously delivering from then on, but this blog entry is about our road to continuous delivery, so my story starts here!
I gave a talk to a group of mechatronics students at KTH (Royal Institute of Technology) today. The topic was agile software development with an emphasis on Scrum, and some information about Kanban and Lean Startup. Here are the slides:
Thanks to everyone who attended the Mobile First Responsive Design Seminar.
If you’re curious about mobile first responsive design, here’s the presentation http://www.yds.se/mobile-first-responsive/:
The “slides” (a mobile first responsive site) are also available on GitHub: https://github.com/crispab/mobile-first-responsive
read more »
read more »
For the past couple of years I’ve had to work with Jira. Really, it’s mostly been dreading working with Jira. At both projects I’ve had Greenhopper available, and that hasn’t really made things better. My frustrations have had to do with the complexity of setting up the right fields, to creating a new sprint to creating a new project, down to mundane things like problems with ranking. I don’t particularly enjoy spending hours just tidying up my data. I want to quickly organize so I have time to actually work. I also want to easily see how much work we’ve done, and how much we have to do. Cards and a physical board are great for this, but I end up with stacks of cards everywhere, and after several sprints I don’t know what to do with them anymore. Enter Trello! read more »
Backbones aren’t the usual fare for tech blogs, but if you’ve been following frontend development, then you’ll have heard of Backbone.js. From their site: Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions,views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface. read more »
The Let’s Test conference (“A European conference on context-driven testing – for testers, by testers”) kicked off today in Sweden. I know, I’m not a tester, so why was I at the conference? Certainly it wasn’t the “context-driven” that drew me, since before I heard of the conference I didn’t really know what that was. The “for testers, by testers” wasn’t so inviting to me as a developer, even though as a member of an agile team I write unit and regression tests, and participate in functional and exploratory testing.
I’ve been playing around with a cool presentation tool, Impress.js by Bartek Szopka.
All you need is an editor, some HTML5 and CSS3 know-how and you’re up and running:
Mercurial is my first serious foray into distributed version control systems (dvcs). When I started gathering my notes for this entry I knew that this would be a really negative review of Mercurial. The first version control system I actually liked was Perforce. Several years later I encountered Subversion, it took a while to adjust but eventually I grew really fond of it. For the past 3 months, I’ve been using Mercurial… definitely not impressed. Or so I thought, but as I looked through my cons, I saw pros all over the place. So here are my [not-so-negative-after-all] thoughts on using Mercurial!
Great retrospectives are amazing, they have a way of really getting a team to work together and to energize them ahead of a new challenge. But even a great retrospective becomes boring and routine after a while. Luckily, there are a lot of us at Crisp working with different teams, so we got together this evening for a peer to peer exchange about retrospectives. We each got to pitch retrospective exercises and games that we’d like to try, or that we wanted to share. We ended up discussing and trying out 9 of them. Here’s a summary in case you’d like to try some of them out at your next retrospective!
I had a conversation with some of my colleagues about what makes a good daily stand-up, here are some properties:
* The team has dumbells by the scrum board. The rule is that if you feel the current speaker is monopolizing the meeting, you can hand the speaker a dumbell. Now the speaker can keep talking only as long as they can hold up the dumbbell with an outstretched arm.