The intersection of technology and leadership

Category: Learning (Page 8 of 15)

Making the mac more usable with keyboard shortcuts

I’m a self confessed keyboard-junkie and avoid using the mouse to do most things. Being new to a mac environment, it’s not necessarily clear how to get some of the usual things done. Inspired by the tip that Thomas wrote here, I figured it’d be worth sharing how I’m navigating my way around. Please leave a comment sharing your favourites!

Enable tabbing to all fields in webforms
The mac apparently wants to make it difficult by default to enter in web forms using a keyboard. Turn on the Full keyboard access option to All Controls. Use the dialog following System Preferences => Keyboard & Mouse => Keyboard Shortcuts page.

EnableTabbingToAllControls

Equivalent of accelerator or access keys
MenuBarMost windows applications provide underlined characters so you can access them with the ALT+<letter> key. In this manner, you can access all items without having to click the mouse.
Mac equivalent: The most effective way I’ve found so far is to use the Help (CMD+SHIFT+?) and then type in the label of the menu item. Use the up and down arrows and enter to select. Note that this isn’t guaranteed to work in all applications (like Firefox opening a help page instead)

Closing windows
Fortunately the CTRL-W option that would close applications maps directly to CMD+W although unlike windows, closing the last windows doesn’t automatically shutdown the application. CMD+Q will do the trick instead.

Opening finder
On windows, I’d use the Windows+E button to open up a new version of windows explorer to look at files. There seems to be a few ways to do this. If you have quicksilver installed, open quicksilver and then start typing Finder. If you’re using spotlight, start typing a file you know exists and then hit CMD+R (reveal in finder).

Unlike windows explorer, finder won’t necessarily always start from the root directory. Use the keyboard shortcuts CMD+SHIFT+H to start from home context or CMD+SHIFT+C to start from the computer context (useful if navigating to network drives).

Scrolling through windows of the same application
Use the CMD+` (backquote) to do so. Use CMD+~ (tilde) to go the other way (or CMD+SHIFT+`)

Show Desktop
On windows, I would use the WIN+M to minimise all windows. On the mac, you can use F5 if you don’t map those keys to normal functions (such as volume control) or if you turn on Expose, you can use F11 to hide all.

Is the term ‘Agile’ still useful?

This year proved interesting for those in the agile community, or at least for me. The most commercialised agile methodology lost one of its largest figureheads, and a new community of thinkers emerged focused on prioritising a practice often implied or described as optional in other methodologies. What I found fascinating about a new community forming is that in finding its own identity, it naturally results in denouncing ties with existing communities (to a certain degree) and comparisons about whether or not they are “agile”.

This lead me to ask myself, “What is wrong with agile?” To better understand it, I went back to finding out why “agile” first started. From my understanding, a community of thinking practitioners (not just thinkers) coined the phrase “agile” to unite people working in different ways to help identify with each other. The actual methods for working in an “agile” fashion existed well before they coined the term.

I respect and heartily thank this group of thinking practitioners for coining the term “agile”. A simple word acting as an umbrella that encourages people to swap ideas between communities. I recognise this same “vagueness” that draws people together also makes it difficult for newcomers to identify with what it means.

Look at how other communities relentlessly protect their set of practices, branding and declaring you are or are not doing methodology X or approach Y, particularly when reinforced with certification programs. I’ve realised this same protectionist attitude acts as a wall to new ideas spreading between people and organisations that could be beneficial.

I vouch that the term “agile” remains useful. Let us not forget the original intent behind the word. Let us embrace and create opportunities to continue welcoming all thinking practitioners from different backgrounds to connect and swap ideas and experiences to be more effective and successful.

Agile Does Not Guarantee Success

Businesses need to be comfortable that not all projects are going to succeed. Out of a portfolio of projects, people need to be comfortable that these projects will not achieve what they originally set out to do. Don’t expect that, even with agile methods and values guiding your teams, these projects will achieve what they set out to do.

Some projects aren’t set up for success. Poor organisational governance, leading to unrealistic expectations established from the outset often set up a project for a real death march. Or perhaps projects spun out of the whims of one set of people only to not understand what organisational capabilities they really have. Sometimes it comes down running a project with the wrong mix of skills and without a support structure in place that creates a time bomb waiting to explode.

Don’t forget that agile and lean methodologies cannot guarantee success. At the heart of it, agile will surface problems and make them visible. Organisations need to be prepared to confront the truth (many are not ready for this level of transparency) and support changes that will make it better.

For projects destined to fail, your best result is often to Fail Fast, take those lessons and then do something differently. Avoid the situation where a project sucks up resources that could be more effectively allocated. And don’t forget, just because a project didn’t achieve what it set out to do, it’s only a true failure if you don’t learn anything from it.

Agile 2009 Session Results Posted

It’s been a few weeks and I’ve finally had a chance to go through all the photos and sticky notes from the “Climbing the Dreyfus Ladder of Agile Practices” workshop I ran at Agile 2009, as promised.

For those that didn’t get to attend, I asked five groups to pick one agile practice out of 12 choices and brainstorm specific behaviours they had observed people participate in. Based on their brainstorming, I then asked everyone to categorise them according to what different level in the Dreyfus Model of Skills Acquisition.

I found it fascinating to see firstly, what behaviours people witnessed, and even more fascinated by the way that groups then tried to classify them. Follow the link above to look at the results.

Agile 2009 Day 2

It’s at the start of the third day to Agile 2009, and I wanted to write up some notes from the conference before I start to fill my head with more ideas from the third day. It’s definitely going to be a slow start to the day, not because the program isn’t interesting, but rather since I’ve had a few hours sleep.

Yesterday was a full day and full in the sense of many wonderful things to think about. Alistair Cockburn kicked off the morning with a keynote titled, “I Come to Bury Agile, Not to Praise It“. Let’s be clear here (Cockburn emphasised this at least three times) as this will no doubt be misinterpreted by people over time: This session was not saying that agile was dead and useless. Rather, that agile has become an everyday part of life, no longer controversial and proven to be good and practical. After all, it’s been around for at least a decade now. Cockburn used the metaphor of an iceberg (agile) melting and forming part of the ocean.

If you get a chance to catch Cockburn speak, I cannot recommend him highly enough. Rather dramatically, he walked on stage following a fellow playing bag pipelines, only to perform a Shakespearen soliloquy completely memorised without notes. Very impressive! I’ll agree with some critics that I don’t think that what Cockburn had to say was controversial, yet that doesn’t automatically make it a bad thing. Cockburn articulates ideas really well, and formed a great story linking what items are essential for software development in the 21st century. On top of this is his great presentation and speaker skills, something very admirable indeed. I also appreciate his humbleness and openness to encouraging others. For example, it’s easy for someone like him to just talk about the work that he does yet he didn’t have any hesitation talking about what interesting work other people were doing, naming them explicitly on stage (something many other people in his position doesn’t do). He really knew the content in the slides, even at the end asking for to jump to content by slide number to bring up diagrams for questions. I also appreciated the fact that he didn’t jump through a generic set of slides, skipping bits that weren’t relevant and spending more time on others. That shows that he at least put thought into how the presentation was going to run for.

After the keynote, another Alistair, this time my great co-presenter, Alistair Jones and I presented our session titled, “Top ten secret weapons for performance testing in an agile environment“. Yes, looking back at it, a bit of a mouthful. We were both really happy with how it went given that the room was almost full and we had lots of questions, both during and after. Admittedly I think 45 minutes was a tight squeeze, however the program’s alternative of 90 minutes would have been far too long to talk for. Thanks to all the people that came along and we’ll be posting the content online somewhere in the near future.

At lunch, I dropped into the Programming with the stars session in the other tower, a fun place to watch different styles of how people approach and present a problem. Well done to all the participants as it takes a lot of courage to step up on stage and put yourself in front of the audience.

Later that day, I went along to the session titled, “What (Else) Can Agile Learn from Complexity?” by Jurgen Appelo that I found pretty interesting only because I’ve been reading more about complexity and chaos and how it applies to everyday life. Pretty heavy technical and term driven presentation yet very helpful for me to see how other people view it applying to software.

This session followed on with the Lean Lego Game by some colleagues, Francisco and Danilo. It’s a great experiential simulation that teaches the concepts of lean that I highly recommend everyone try. In fact, the only pitfall for their session was the fact that too many people turned up, making it difficult for two people to facilitate such a workshop.

Last night (and following through to early this morning) ThoughtWorks hosted an Agile Open Office and helped launch the Agile and PMI initiative to bring those two communities together. If you’re interested working with the PMI, they’re looking for agilistas to meet with a local PMI branch all around the world. I met some really fascinating people and far too many topics to even cover in this time.

Speaking at Agile 2009

Presenting at Agile 2009I’m excited to announce that I will be running my workshop again, Climbing the Dreyfus Ladder of Agile Practices at the Agile 2009 conference in just over a week’s time. This is the same workshop that I hosted at XP2009 in Italy. In addition to this, my great colleague Alistair Jones and I will also be co-presenting an experience report, Top ten secret weapons for performance testing in an agile environment. Hope you can make it to one of these. I’m really excited to be sharing some lessons I’ve learned along the way.

I’m keeping a page from the session here.

XP2009 Day 3

The keynote
Bjarte Bogsnes gave, in my opinion, the best keynote out of the three speakers, where he discussed his experiences applying the concepts discussed in Beyond Budgeting in Statoil. He talks about why do you want a system that is based on assuming you cannot trust everyone? Instead you want a system where the default position is that you trust everyone, and that you manage those that you can’t by exception (and not the other way around).

He talked about how the trigger for Statoil was two fold – internal and external. External pressures included the fluctuating nature of the sale price for barrels of oil, and internally it was the social pressures of actually having systems that encouraged all the good things that they said they did, yet didn’t neccessarily encourage, where policies were largely authority based (sign off) compared to those of trust and respect.

The key question they asked was, “How do we create the conditions that let people make good decisions and execute them well?” Compare this to, “How do we make people make good decisions and execute them well?”.

Interesting their solution laid in removing the “traditional” budgeting scheme, asking people to “do the right thing”. Resources were available but not yet preallocated. I remembered most his metaphor, describing most businesses operating like a bank that is open for four weeks out of the week. Customers need to predict exactly what their year is going to be like, and ask exactly for the right amount.

They identified that budgets typically have three overloaded (and often opposing goals), representing performance targets, forecasts and resource allocation. They implemented a system splitting each of these different aspects into different systems to achieve better visibilty and improve the quality of conversations around each of these topics. They created a system to ensure there was alignment at all different levels, directly creating KPIs out of the strategy, generating actions out of the KPIs and then individual goals out of the actions.

Industrial Logic’s eLearning Tool
I had a great chat with Joshua Kerievsky, founder of Industrial Logic and he asked if I wanted to see their “eLearning” tool. I’m glad I did as well because I think it’s an amazing environment for all developers who want to be professional. I don’t think calling it an “eLearning” tool does it justice. In a nutshell:

Imagine gathering some of the world’s best experts in different programming disciplines such as refactoring, automated testing, design patterns and imagine working with them on the same team. You get to watch over their shoulder as they explain what they’re thinking as they execute, you get to practise an exercise with them and receive immediate feedback, and you get to interact with the most engaging pieces of training I’ve ever seen (including many of the hands on training classes). All of this just happens to be online.

They’ve put a tremendous amount of effort responding to student’s feedback and its narrow focus on (currently) developer related material means they can give some surprisingly detailed feedback including comparisions and alternatives as a result. The tool itself only happens to help deliver the message and, more importantly, he’s managed to capture so much knowledge in the “albums” they’ve already put together.

Go check it out. Take the tour and then have a look at some of the albums.

Telling Your Stories: Why Stories Are Important for Your Team
Fellow retrospective facilitators Diana Larsen and Johanna Hunt ran a fun session that was particularly engaging considering, managing to have the busiest session on the last slot of the last day. The title of the workshop didn’t describe the session as accurately as it panned out as it was extremely creative workshop where we looked a number of a card games often used for story telling in other areas, and then brainstormed ways in which we could create cards and a process to help use stories in an agile environment. The group had some fantastic ideas and even heard a few people walk away saying, “I need to get some of those cards made!” to take back to their teams.

Conclusion
I’m pleased that this year’s conference seemed to have returned to what roots it was for me four years ago. I appreciate the fact that there are still so many people passionate about “doing the right thing”, about helping each other out, and that the main motivator is still to “grow, learn and get better” first, instead of “making money” prioritised as number one. Thanks to all the wonderful people I met at this conference (for the first time and again), and the great memories I took away.

XP2009 Day 2

Thoughts about the second day
Ivar Jacobson gave an equally uninspiring keynote, talking about “What they don’t teach you about software at school: Be Smart!” In it, he focuses on the fact that it’s not only enough to try to “Be Agile”, but you need to “Be Smart”. Unfortunately many of the items that he talked about didn’t really seem to be any different from “Being Agile” and that he had obviously targeted the wrong audience.

I’m glad the conference ran with an open space session, this year introduced by Willem Van Den Ende and Lasse Koskela. I suggested a topic titled, “The Kanban, Lean, Agile Divide” and I felt we had the best quality discussions during this open space. I wanted to answer a number of questions including:

  • Did people know about the Kanban Community?
  • How active were people in that community?
  • Did people perceive a divide?
  • And if so, why?

Out of around the 12 people participating, probably only two or three hadn’t heard about the community, and only one or two people were active in participating (in the mailing list portions). We had lots of discussion as to what people considered as Kanban as well.

kanban

First page of notes from the open space session

We noted down the mailing list, available on Yahoo Groups: Kanban-Dev and several “published” resources including the paper, Kanban Vs Scrum, and the book, Scrumban.

When asked about what Kanban was the participants, here’s what we recorded:

  • Elements of one piece flow (particularly limits to WIP or Work In Progress). Translated into practical terms, it meant focusing on one story at a time (as a team or as a pair)
  • Kanban was an alternative scheduling technique
  • Unprescriptive, or less prescriptive (relying on other practices to help out)
  • Constantly evolving
  • “Good for maintenance”
  • Most people considered Kanban a “Practice more than a methodology”, though there was general agreement that some people are trying to turn it into more than that
  • Focused on delivering “Minimal Marketable Features”
  • Quote from Tom Poppendieck, “Scheduling and Workflow are orthogonal”. We expanded upon this for a bit and a more concrete example is you can use different scheduling techniques such as Kanban or Timeboxes with the same workflow such as a simple, “To Do, In Progress, Done” workflow.

I recorded that some people were still doing sprint/iteration planning whilst using Kanban though I don’t remember if we got into the details.

I also recorded two concerns, such as knowing, “When do we get stuff done?” and a very “Loose Terminology” leading to lots of confusion, particularly the overloaded associate with Kanban (as a practice) and Kanban (as a methodology).

When asking the question, “Is there a kanban divide?” some answers included, there is maybe a divide in a community sense, and when probing further, when interpreting Kanban as a practice, not a methodology there wasn’t however there was definitely a sense when treating Kanban as a methodology and not as the practice with a feeling that some people in the community wanted to make money.

kanban2

Last page of notes from the open space session

We asked why the community divide and understandably, there was no real community around to openly discuss Kanban (as a practice) and felt similar to those that had been around during the XP early days. There didn’t seem to be any general list for “agile practices” with extremeprogramming and scrum-dev mailing lists. It’s also not the first time practices have had their own list, like the pairprogramming or the test-driven-development lists. We did note down that there were several potential ones the community could have joined including lean-agile, lean-dev instead of creating their own kanban-dev.

In the afternoon, I went along to the panel on Lean Software Development although I seemed to come away with the same questions and less answers. One of my questions about budgeting was answered by the next morning’s keynote, while another focusing around the lack of discussion around practices seemed to be dismissed by Mary Poppendieck as, “I don’t believe in practices”, maybe best surmised as, “I don’t know” (which I would have also been happy to take).

The evening was an impromptu beach BBQ held by the awesome folks at Agical. Whilst a small company, I’m glad to see them still as passionate and having grown year upon year with more enthusiasm about a huge variety of topics. The BBQ was amazing and I know that everyone had a great time.

More to come…

XP2009 Day 1

General impressions about the conference
I really enjoyed this year’s conference with the combination of a remote island in Italy and the small numbers (100+) giving many great opportunities for chatting with our experienced practitioners, and a handful of academics about lots of different topics. I found it refreshing that there seemed to be significantly more experienced practitioners and thus, I found it extremely nice to be able to chat about similar experiences rather than simply unidirectional advice I find when present with a higher proportion of beginners.

conferencepool

Who wouldn’t want to gather around this place for some great conversations?

The quality of sesions was better than the last two conferences, once again focused less on the introductory nature and more focused on specific aspects. Of course, I had recommendations about how to improve, particularly the organisational aspects, of the conference and I’ve at least had an opportunity to give that feedback having shared a return train with one of the organisers for next year’s conference.

Thoughts about the first day
The first part of this day was a keynote delivered by lean evangelist, Mary Poppendieck. Titled, “The Cultural Assumptions behind Agile Software Development”, Mary proposed that there are several (American-style) cultural assumptions behind many of the agile practices that make it all the more difficult to implement. She referenced heavily the work discussed by Geert Hofsted in his book, Cultural Dimensions.

I didn’t find the keynote particularly inspiring, nor particularly challenging. Country-based cultural dimensions are just one of the factors that permeate the way that people behave. As an agile consultant, you end up fighting corporate culture, and the systems that encourage and maintain that corporate culture and I see country-based cultural dimensions yet another contributing systemic effect. This does not mean that just because a country has a high degree of individualism, working in pairs or working collaboratively in a team will be impossible (perhaps just all the more difficult). As much as I enjoy hearing Mary speak, I also found her presentation a little bit too heavy in the whole powerpoint presentation with far too much text and outdated clipart.

I also ran my workshop in the morning, titled “Climbing the Dreyfus Ladder of Agile Practices” and want to thank all the experienced people that attended as it resulted in some really rich discussions. We managed to discuss seven different agile practices in detail, brainstormed a large set of behaviours for each, classifying them and classifying them into the different levels described the the Dreyfus Model of Skills Acquisition. The results from the workshop can be found here (photos to be updated).

In the afternoon, I helped out Emily Bache’s coding dojo, focused on Test Driven Development. We saw four different pairs tackling four different coding problems using different tools and languages. I learned about the tool JDave (it’s still a little bit too verbose for my liking), and saw different styles in the way that people executed the code kata. For me, I was hoping to demonstrate more on the pair programming side of test driven development as a pair, and I had a lot of fun even though I felt a little bit out of my depth with the tools. Thanks to Danilo for complementing my lack of experience with tools like Cucumber. 🙂

More to come…

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑