Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator

What craftsmanship means to me

Actively Lazy - Tue, 03/21/2017 - 22:39

Over a decade ago now I got my first team lead role. It was a reasonably unexpected promotion when the existing team lead left shortly after I joined. This baptism of fire introduced me to line management, but also made me question my career choice. But it was, in hindsight, the beginning of a new journey: of becoming a software craftsman.

With barely 5 years experience I was certainly no senior developer. And yet, here I had been thrust, into a team lead role. With so little experience I made many, many mistakes and was probably a pretty rubbish boss for the three other guys on the team. I tried my best. But the whole process was very draining. But worse, I started to see programming at a more abstract level. In charge of a team, I could see that all we were was a factory for turning requirements into working code. The entire process began to feel like turning a handle: feed the team requirements, some praise and a little coffee and out comes working code.

In the end, a lot of software ends up being very similar: how many CRUD apps does the world really need? Turns out billions of them. And yet, in conception, they’re not massively exciting. Take a piece of data from the user, shovel it back to the database. Take some data out of the database, show it to the user. All very pedestrian. All very repetitive. In this environment it’s easy to become disillusioned with the process of building software. A pointless handle turning exercise.

I moved on from this baptism of fire to my first proper management role. Whereas previously I was still writing code, now I was effectively a full-time manager. I was the team’s meeting and bullshit buffer. It took a lot of buffering. There was a lot of bullshit. I think we even once managed a meeting to discuss why productivity was so poor: maybe the vast number of meetings I was required to attend each day? Or could it have been the 300 emails a day that arrived in my inbox?

If I was disillusioned with the process of writing software before, I now became disillusioned with the entire industry. A large company, little more than a creche for adults, continuing forwards more out of momentum than anything else. Plenty of emails and meetings every day to stop you from having to worry too much about any of that pesky work business.

It was then that I opened my eyes and saw there was a community outside. That programmers across the world were meeting up and discussing what we do. The first thing I saw was the agile community – but even back then it already looked like a vast pyramid scheme. But I was encouraged that there was something larger happening than the dysfunctional companies I kept finding myself working for.

Then Sandro Mancuso and I started talking about software craftsmanship. He introduced me to this movement that seemed to be exactly what I thought was missing in the industry. Not the agile money-go-round, but a movement where the focus is on doing the job right; on life-long learning; on taking pride in your work.

Not long afterwards Sandro and I setup the London Software Craftsmanship Community, which quickly snowballed. It seems we weren’t alone in believing that the job can be done well, that the job should be done well. Soon hundreds of developers joined the community.

The first immediate consequence of my involvement in the software craftsmanship community was discovering a new employer: TIM Group. A company that genuinely has a focus on software built well, with pair programming and TDD. A company where you can take pride in a job done well. The most professional software organisation I’ve worked in. They’re almost certainly still hiring, so if you’re looking, you should definitely talk to them.

Finally I’d found the antidote to my disillusionment with how software is often built: the reason I was frustrated is that it was being built¬†badly. That companies often encourage software to be built slapdash and without care, either implicitly or sometimes even explicitly. If building software feels like just turning a handle it’s because you’re not learning anything. If you’re not learning, it’s because you’re not trying to get better at the job. Don’t tell me you’re already perfect at writing software, I don’t believe it.

Through software craftsmanship I rediscovered my love of programming. My love of a job done well. The fine focus on details that has always interested me. But not just the fine details of the code itself: the fine details of how we build it. The mechanics of TDD done well, of how it should feel. I discovered that as I became more senior not only did I find I had so much more to learn, but now I could also teach others. Not only can I take pride in a job done well, but pride in helping others improve, pride in their job done well.


Categories: Programming, Testing & QA

Introducing Android Native Development Kit r14

Android Developers Blog - Tue, 03/21/2017 - 21:58
Posted by Dan Albert, Android NDK Tech Lead

Android NDK r14
The latest version of the Android Native Development Kit (NDK), Android NDK r14, is now available for download. It is also available in the SDK manager via Android Studio.

So what's new in r14? The full changelog can be seen here, but the highlights include the following:
  • Updated all the platform headers to unified headers (covered in detail below)
  • LTO with Clang now works on Darwin and Linux
  • libc++ has been updated. You can now use thread_local for statics with non-trivial destructors (Clang only)
  • RenderScript is back!

Unified Headers We've completely redone how we ship platform header files in the NDK. Rather than having one set of headers for every target API level, there's now a single set of headers. The availability of APIs for each Android platform is guarded in these headers by #if __ANDROID_API__ >= __ANDROID_API_FOO__ preprocessor directives.

The prior approach relied on periodically-captured snapshots of the platform headers. This meant that any time we fixed a header-only bug, the fix was only available in the latest version aside from the occasional backport. Now bugfixes are available regardless of your NDK API level.

Aside from bugfixes, this also means you'll have access to modern Linux UAPI headers at every target version. This will mostly be important for people porting existing Linux code (especially low-level things). Something important to keep in mind: just because you have the headers doesn't mean you're running on a device with a kernel new enough to support every syscall. As always with syscalls, ENOSYS is a possibility.

Beyond the Linux headers, you'll also have modern headers for OpenGL, OpenSLES, etc. This should make it easier to conditionally use new APIs when you have an older target API level. The GLES3 headers are now accessible on Ice Cream Sandwich even though that library wasn't available until KitKat. You will still need to use all the API calls via dlopen/dlsym, but you'll at least have access to all the constants and #defines that you would need for invoking those functions.
Note that we'll be removing the old headers from the NDK with r16, so the sooner you file bugs, the smoother the transition will go.

Caveats The API #ifdef guards do not exist in third-party headers like those found in OpenGL. In those cases you'll receive a link time error (undefined reference) rather than a compile time error if you use an API that is not available in your targeted API level.

Standalone toolchains using GCC are not supported out of the box (nor will they be). To use GCC, pass -D__ANDROID_API__=$API when compiling.

Enabling Unified Headers in Your Build To ease the transition from the legacy headers to the unified headers, we haven't enabled the new headers by default, though we'll be doing this in r15. How you opt-in to unified headers will depend on your build system.

ndk-build
In your Application.mk:

    APP_UNIFIED_HEADERS := true
You can also set this property from the command-line like this:

    $ ndk-build APP_UNIFIED_HEADERS=true

If you're using ndk-build via Gradle with externalNativeBuild, specify the following configuration settings in build.gradle:

    android {
      ...
      defaultConfig {
        ...
        externalNativeBuild {
          ndkBuild {
            ...
            arguments "APP_UNIFIED_HEADERS=true"
          }
        }
      }
    }
CMake When configuring your build, set ANDROID_UNIFIED_HEADERS=ON. This will usually take the form of invoking CMake with cmake -DANDROID_UNIFIED_HEADERS=ON $OTHER_ARGS.

If you're using CMake via Gradle with externalNativeBuild, you can use:

    android {
      ...
      defaultConfig {
        ...
        externalNativeBuild {
          cmake {
            ...
            arguments "-DANDROID_UNIFIED_HEADERS=ON"
          }
        }
      }
    }
Standalone Toolchains When creating your standalone toolchain, pass --unified-headers. Note that this option is not currently available in the legacy script, make-standalone-toolchain.sh, but only in make_standalone_toolchain.py.

Experimental Gradle Plugin Coming soon! Follow along here.

Custom Build System? We've got you covered. Instructions on adding support for unified headers to your build system can be found here.

For additional information about unified headers, see our docs and the tracking bug. If you're looking ahead to future releases, the most up-to-date version of the documentation is in the master branch.
Categories: Programming

Get a sneak peek at Android Nougat 7.1.2

Android Developers Blog - Tue, 03/21/2017 - 19:21
Posted by Dave Burke, VP of Engineering

The next maintenance release for Android Nougat -- 7.1.2 -- is just around the corner! To get the recipe just right, starting today, we're rolling out a public beta to eligible devices that are enrolled in the Android Beta Program, including Pixel and Pixel XL, Nexus 5X, Nexus Player, and Pixel C devices. We're also preparing an update for Nexus 6P that we expect to release soon.

Android 7.1.2 is an incremental maintenance release focused on refinements, so it includes a number of bugfixes and optimizations, along with a small number of enhancements for carriers and users.

If you'd like to try the public beta for Android 7.1.2, the easiest way is through the Android Beta Program. If you have an eligible device that's already enrolled, you're all set -- your device will get the public beta update in the next few days and no action is needed on your part. If your device isn't enrolled, it only takes a moment to visit android.com/beta and opt-in your eligible Android phone or tablet -- you'll soon receive the public beta update over-the-air. As always, you can also download and flash this update manually.

We're expecting to launch the final release of the Android 7.1.2 in just a couple of months, Like the beta, it will be available for Pixel, Pixel XL, Nexus 5X, Nexus 6P, Nexus Player, and Pixel C devices. Meanwhile we welcome your feedback or requests in the Android Beta community as we work towards the final over-the-air update. Thanks for being part of the public beta!
Categories: Programming

TDD is not about unit tests

Xebia Blog - Tue, 03/21/2017 - 14:42

-- Dave Farley & Arjan Molenaar On many occasions when we come at a customer, we're told the development team is doing TDD. Often, though, a team is writing unit tests, but it's not doing TDD. This is an important distinction. Unit tests are useful things. Unit testing though says nothing about how to create […]

The post TDD is not about unit tests appeared first on Xebia Blog.

How to Add the Right Amount of Detail to User Stories

Mike Cohn's Blog - Tue, 03/21/2017 - 13:00

This blog post refers to a four-part series of videos on overcoming challenges with user stories. Topics covered are conducting story-writing workshops with story maps, splitting stories, and achieving the right level of detail in user stories.

To be notified when you the videos are again available, sign up below:

Notify Me!

Today’s post introduces the third installment in a free series of training videos all about user stories. Available for a limited time only, you can watch all released videos by signing up to the Better User Stories Mini-Course. Already signed up? Check your inbox for a link to the latest video, or continue reading to find out about today’s lesson.

An extremely common problem with user stories is including the right amount of detail.

If you include too much detail in user stories this makes story writing take longer than it would otherwise. As with so many activities in the business world, we want to guard against spending more time on something than necessary.

Also, spending time adding too much detail leads to slower development as tasks like design, coding, and testing do not start until the details have been added. This delay also means it takes longer for the team and its product owner to get feedback from users and stakeholders.

But adding too little detail can lead to different but equally frustrating problems. Leave out detail and the team may struggle to fully implement a story during a sprint as they instead spend time seeking answers.

With too little detail, there’s also an increased chance the development team will go astray on a story by filling in the gaps with what they think is needed rather than asking for clarification.

There’s danger on both sides.

But, when you discover how much detail to add to your stories, it’s like Goldilocks finding the perfect bowl of porridge. Not too much, not too little, but just right.

But how do you discover how much is the right amount?

You can learn how in a new, 13-minute free video training I’ve just released. It’s part of the Better User Stories Mini-Course. To watch the free video, simply sign up here and you’ll get instant access.

Remember, if you’ve already signed up to the course you don’t need to sign in again, just go to www.betteruserstories.com and video #3 will already be unlocked for you.

Adding the right amount of detail--not too much, not too little--is one of the best ways to improve how your team works with user stories. I’m confident this new video will help.

Mike

P.S. This video is only going to be available for a very short period. I encourage you to watch it now at www.betteruserstories.com.

Becoming an Agile Leader, Part 5: Learning to Learn

To summarize: your agile transformation is stuck. You‚Äôve¬†thought about your why, as in¬†Becoming an Agile Leader, Part 1: Define Your Why.¬†You‚Äôve started to measure possibilities. You have an idea of who you might talk with as in¬†Becoming an Agile Leader, Part 2: Who to Approach.¬†You‚Äôve considered¬†who you need as allies and how to enlist them in Becoming an Agile Leader, Part 3: How to Create Allies. In¬†Becoming an Agile Leader, Part 4: Determining Next Steps, you thought about creating win-wins with influence. Now, it’s time to think about how you and the people involved (or not involved!) learn.


As an agile leader, you learn in at least two ways: observing and measuring what happens in the organization. (I have any number of posts about qualitative and quantitative measurement.) Just as importantly, you learn by thinking, discussing with others, and working with others. The people in the organization learn in these ways, too.

The Satir Change Model is a great way of showing what happens when people learn. (Learning is a form of change.) Here’s the quick intro to the Change Model: We start off in Old Status Quo, what we did before. Along comes a Foreign Element, where someone introduced some kind of change into the environment. We have uneven performance until we discover our Transforming Idea. Once we have an idea that works, we can continue with Practice and Integration until we have more even performance in New Status Quo.

In the Influential Agile Leader, you have a chance to think alone with your pre-work, by discussing together such as when you draw your map in Part 1, and by working together as in coaching and influence and all the other parts of the day. One of the most important things we do is to debrief all the activities just after you finish them. That way, people have a chance to articulate what they learned and any confusions they still have.

Every person learns in their own way, at their own pace. With interactions, simulations, and some thinking time, people learn in the way they need to learn.

We don’t tell people what to do or how to think. We suggest options we’ve seen work before (in coaching). We might help supply some options for people who don’t know of alternatives. And, the participants work together. Each person’s situation is a little different. That means each person has experiences that enrich the entire room.

Learn to be an agile leader and help your agile transformation progress. Please join us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Mon, 03/20/2017 - 15:44

You can sway a thousand men by appealing to their prejudices quicker than you can convince one man by logic. ‚Äď Robert A. Heinlein, Revolt in 2100

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Mon, 03/20/2017 - 15:44

You can sway a thousand men by appealing to their prejudices quicker than you can convince one man by logic. ‚Äď Robert A. Heinlein, Revolt in 2100

Categories: Project Management

Software Development Linkopedia March 2017

From the Editor of Methods & Tools - Mon, 03/20/2017 - 14:25
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about sharing information, team conflicts, leadership, meetings, DevOps, test management, refactoring software architecture, pair testing, software design and scaling Agile. Text: How I Share Information with my Team Text: Helping Teams […]

Where is the Adult Supervision on this Program?

Herding Cats - Glen Alleman - Mon, 03/20/2017 - 01:34

Most programs I work are in trouble in some form - other wise they would not have hired us to help. 

One quote we use to describe these situations is

What's the difference between this program and the Boy Scouts? The Boy Scouts have adult supervision.

But today I sat through an out brief from a government auditing agency on a $10B program and one of my colleagues made this statement

This program is like a house with 4 teenage boys, where the parents went on vacation and never returned.

When we encounter these situations, it is tempting to start providing solutions. This is a serious mistake unless we have done the Root Cause Analysis of the observed problem. It may turn out what is being observed is the symptom of a root cause that was not understood by the people that hired us.

This is a rookie mistake in the process improvement business. I see it all the time. Some self-proclaimed thought leader pontificates on what is wrong with the software industry. Makes blanket statements like the current software development methods have not made much difference in the general success in the software development - the software crisis. That is according to the much debunked Standish Reports.

The charts showing software project failures, challenged or otherwise, never seem to have a root cause of the failure or less than desired performance. Same is the case with those advocating that the Cone of Uncertainty doesn't match how the work proceeds on their projects. 

Why? Why are you seeing what you're seeing? What are the possible causes of these observations?

Like most voices pointing out obvious difficulties in writing software for money, without identifying the Root Cause, the proposed solutions have no basis for testing their fix will actually fix anything. 

Most of the time when we come onboard to put the project back on track, we find missing processes, missing data produced from those processes, and most of the time people behaving badly. Now you could make the case that it starts with the people. Which is a noble conjecture and could possibly be true. 

But the naive notion that people can operate on a non-trivial in the absence of a process is just that - naive. 

One place to start is Identifying Acquisition Framing Assumptions Through Structured Deliberation 

Related articles Estimating and Making Decisions in Presence of Uncertainty The Dysfunctional Approach to Using "5 Whys" Managing in Presence of Uncertainty Herding Cats: Cone of Uncertainty - Part Cinq (Updated) Five Estimating Pathologies and Their Corrective Actions Are Estimates Really The Smell of Dysfunction? Estimating Probabilistic Outcomes? Of Course We Can! Herding Cats: Software Development for the 21st Century
Categories: Project Management

SPaMCAST 434 ‚Äď Big Bang or Not, Human Side of Flow, Fermi Questions

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 434 features our essay on Change Implementations РTo Big Bang or Not To Big Bang? The knee jerk reaction amongst transformation leaders is usually a loud NO! However, the answer is not nearly that cut and dry.  Big Bang approaches to change have a place in bag of tricks every transformation leader has at their fingertips.

The second column this week is from Steve Tendon. Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment, we talk about Chapter 16, The (Super)-Human Side of Flow. In Chapter 16 Steve and Wolfram go into detail on in Kotter’s attributes of flow state.  A good discussion and a good read.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses Fermi Problems. Fermi problems or questions are a tool to teach approximation and estimation.  These problems usually can be solved logically as a back-of-the-envelope calculation. The last time we talked about Fermi Problems was when we were re-reading How To Measure Anything (Hubbard).

Re-Read Saturday News

This week we tackle Chapter 7 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets. Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have ‚Äúread‚ÄĚ from the point of view of both someone pursuing an organizational transformation and using the material when coaching teams. ¬†

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our interview with Allan Kelly.  Our discussion touched on the concepts behind #NoProject.  Allan describes how the concept of projects leads to a number of unintended consequences.  Those consequences aren’t pretty.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

 


Categories: Process Management

SPaMCAST 434 - Big Bang or Not, Human Side of Flow, Fermi Questions

Software Process and Measurement Cast - Sun, 03/19/2017 - 22:00

The Software Process and Measurement Cast 434 features our essay on Change Implementations - To Big Bang or Not To Big Bang? The knee jerk reaction amongst transformation leaders is usually a loud NO! However, the answer is not nearly that cut and dry.  Big Bang approaches to change have a place in bag of tricks every transformation leader has at their fingertips.

The second column this week is from Steve Tendon. Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment, we talk about Chapter 16, The (Super)-Human Side of Flow. In Chapter 16 Steve and Wolfram go into detail on in Kotter’s attributes of flow state.  A good discussion and a good read.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses Fermi Problems. Fermi problems or questions are a tool to teach approximation and estimation.  These problems usually can be solved logically as a back-of-the-envelope calculation. The last time we talked about Fermi Problems was when we were re-reading How To Measure Anything (Hubbard).

Re-Read Saturday News

This week we tackle Chapter 7 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets. Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have ‚Äúread‚ÄĚ from the point of view of both someone pursuing an organizational transformation and using the material when coaching teams. ¬†

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our interview with Allan Kelly.  Our discussion touched on the concepts behind #NoProject.  Allan describes how the concept of projects leads to a number of unintended consequences.  Those consequences aren’t pretty.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

 

Categories: Process Management

Python 3: TypeError: Object of type ‚Äėdict_values‚Äô is not JSON serializable

Mark Needham - Sun, 03/19/2017 - 17:40

I’ve recently upgraded to Python 3 (I know, took me a while!) and realised that one of my scripts that writes JSON to a file no longer works!

This is a simplified version of what I’m doing:

>>> import json
>>> x = {"mark": {"name": "Mark"}, "michael": {"name": "Michael"}  } 
>>> json.dumps(x.values())
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/json/__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
  File "/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
  File "/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/json/encoder.py", line 180, in default
    o.__class__.__name__)
TypeError: Object of type 'dict_values' is not JSON serializable

Python 2.7 would be perfectly happy:

>>> json.dumps(x.values())
'[{"name": "Michael"}, {"name": "Mark"}]'

The difference is in the results returned by the values method:

# Python 2.7.10
>>> x.values()
[{'name': 'Michael'}, {'name': 'Mark'}]

# Python 3.6.0
>>> x.values()
dict_values([{'name': 'Mark'}, {'name': 'Michael'}])
>>> 

Python 3 no longer returns an array, instead we have a dict_values wrapper around the data.

Luckily this is easy to resolve – we just need to wrap the call to values with a call to list:

>>> json.dumps(list(x.values()))
'[{"name": "Mark"}, {"name": "Michael"}]'

This versions works with Python 2.7 as well so if I accidentally run the script with an old version the world isn’t going to explode.

The post Python 3: TypeError: Object of type ‘dict_values’ is not JSON serializable appeared first on Mark Needham.

Categories: Programming

Quote of the Day

Herding Cats - Glen Alleman - Sun, 03/19/2017 - 01:55

Insight, untested and unsupported, is an insufficient guarantee of truth. - Bertrand Russell, Mysticism and Logic 1929

When we hear an extraordinary claim, demand extraordinary evidence.

Categories: Project Management

Mindset: The New Psychology of Success: Re-Read Week 8, Chapter 7, Parents, Teachers, Coaches: Where Do Mindsets Come From?

Mindset Book Cover

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy.  After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me).

Today, we review Chapter 7 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets.Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change.

Dweck begins Chapter 7 by reinforcing the concept that parents learn very early, every word and action send a message. The rubber hits the road when that message gets interpreted by the recipient.  As we established earlier in the book, those with a fixed mindset interpret any message as a judgment.  Those with a growth mindset will interpret words and actions as feedback that can be used to become better and that the person that is sending the message is interested in their development.

Messages that focus on the outcome rather than the journey tend to have a very short-term impact.  These types of message provide a quick shot of adrenalin. A number of years ago, my wife, eldest daughter and I walked the Inca Trail to Machu Picchu.  It was a difficult hike and provided us an opportunity to contemplate the world and our place in the world. As we toured Machu Picchu at the end of the hike we ran into people that had simply taken the train and could not understand why we had spent the time and effort on the walk.  In our minds, the journey was integral to the whole experience rather than just jumping on and off a train. The realization that the journey important is a part of the learning process defines a person with a growth.  Parents and teachers should send the message that the journey is important by praising both efforts and achievements. A simple message that skills and achievement come through commitment and effort impacts the individual the message is targeted toward and those around them.  All messages once sent are heard and passed on.  Anyone in the teacher, parent, or coach role must continually is if the message being sent is to judge, punish or to help the recipient think and learn.

Much of the chapter is focused on what makes a great teacher, parent or coach.  One of the primary messages Dweck sends in this chapter is that parents and teachers must believe (and send the message) that effort is required to learn and grow.  Talent is not innate, but learned and honed.  Parents and teachers need to establish high standards, provide a nurturing environment and the tools to learn.  Teachers, parents, and coaches with a growth mindset tell the truth about the learner’s gaps in performance and then provide them with the tools to overcome that gaps.  The gaps in performance do not define the person because the assumption is that they will continual to learn and grow.

Organizational Transformation:  Messaging is an important part of all transformations.  The message that frames the transformation has to truthfully identify gaps and performance and the tools that will be deployed to close those gaps.  The tone needs to highlight the growth that effort and the journey will bring to the organization. In any longer term transformation effort will require continual messaging, the same tone needs to be leveraged as progress is made.

Team Coaching: The advice in this chapter can be applied at the team level. Team coaches have to approach helping teams with a growth mindset. Coaches need to assess the teams they work with, share performance gaps, help to envision a better future state and then provide the support and tools needed to grow.  Coaches without a growth mindset rarely will be able to generate a nurturing environment that will convince team members that they are not be judged and graded which will reinforce fixed mindsets.   

 

Previous Entries of the re-read of Mindset:

Basics and Introduction

Chapter 1: Mindsets

Chapter 2: Inside the Mindsets

Chapter 3: The Truth About Ability and Accomplishment

Chapter 4: Sports: The Mindset of a Champion

Chapter 5: Business: Mindset and Leadership

Chapter 6: Relationships: Mindsets in Love (or Not)

 


Categories: Process Management

Operations, Finance, and Accounting for the Development of Software

Herding Cats - Glen Alleman - Fri, 03/17/2017 - 21:21

It's common to hear, projects are overhead, we just need to get the value to the customer as fast as possible. This seems to be a lament from agile developers. Anything getting in the way of them coding is seen as an impediment. 

Here's a little story.

Long ago (1978) in a land far away (Redondo Beach) I too wrote code and continued to write code for a decade or so after that. This code was for a Missile Defense system - Cobra Dane and a few satellites that supported it. My boss was a crusty engineer with a long history of delivering products to the DOD that showed up on time and on budget and worked in the defense of the nation. When us young pups arrived to move the development processes into the next century (minicomputers, high-level languages, integrated development environments) from the previous generation of punching holes in pieces of paper - either card stock or rolls of paper tape - we thought we were clearly superior to those of the past generation and were proud to tell anyone who wold listen how we had a lock on what to do best.

After tolerating our attitudes for a few months - and it was good work which is why we were hired and continued to work there for many years - Fred had a little talk. It was clear many years later, he was a good development manager and waited for the appropriate time to coach and mentor us.  In those days we got a paper paycheck and took it across the street to the Bank of America and deposited it every other Friday. The checks were handed out in envelopes by Fred personally. 

Take out your paycheck boys (very few women in those days, although my next boss - Carol - was one of the best) and look in the upper left-hand corner. It says Bank of America and the name of our company (TRW). Well, I just want to clear up a misconception here. That's not where that money comes from. The money on that check comes from the United States Airforce. The Bank of America is just holding it until you cash it. It's the United States Air Force that pays your salary and mine, and the United States Air Force wants us to do our work in the way they want, not the way you want or the way you think they want. So please consider that the next time you get some cockamamy idea that your way of doing things is better than the United States Air Force thinks you should do it. It's their money.

He liked to emphasize the full name of the customer, point out the blue suiters walking around Building O6 in Redondo Beach, not as just customers, but US Air Force customers. I work in that same domain 30 years later. Eat lunch with uniformed staff, shop at noon with stores containing uniformed personnel, stay at hotels, where uniformed personnel are eating. It's a unique environment. but one where Process is King since the money for or work comes from a sovereign.

That was a long story, so here's the point.

Screen Shot 2017-03-17 at 8.24.15 AMThe notion that process and overhead are a waste is true in some sense.

Too much process, too much overhead is a waste. But it's not your money so process and overhead are part of spending that money. And most of all, the amount of process and overhead is not likely your decision unless that decision has been assigned to you. This is how business works.

A Scrum of people works very well when doing Scrum, but operations, finance, and accounting are not the same as writing software for money. A Scrum of cost accountants, planner, finance, and operations people is called Chaos. It works for coders, not so much for others.

Projects are operational, financial, and accounting vehicles for managing and keeping track of that money. What I learned from Fred was this...

Without an understanding of where my paycheck came from, how the customer's money was turned into salaries, those salaries turned into products, and those products turned into revenue, we (all us young pups) were going to continue in our roles of being just labor. 

In those days, TRW sent a few of us back to school (MS, Systems Management, USC) to learn how to put to work the words in the book of one of the founders of our little firm, The Management of Innovative Technological Corporations, Simon Ramo, who was the R in Thompson, Ramo, and Woolrich.

There doesn't seem to be many Fred's in the world of the internet. They're still there at my clients. It's a Value at Risk thing in my opinion. 

If you hear #NoProjects, #NoManagement, #NoEstimates, #NoPlans and the people saying that are at a firm making good margin on millions of dollars of revenue good for them.

But ask how they submit the month end financial report to the investors or stockholders. You may find out they account for all that money in some form of a project - finite bounded set of work that converts cost into revenue and what's left is profit. That those numbers are assigned to discrete buckets of cost, revenue, and project and they call that a project since it's a handy way to keep all the money from getting all mixed up.

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Stuff The Internet Says On Scalability For March 17th, 2017

Hey, it's HighScalability time:

 

Can it be a coincidence trapping autonomous cars is exactly how demons are trapped on Supernatural?
If you like this sort of Stuff then please support me on Patreon.
  • billion billion: exascale operations per second; 250ms: connection time saved by zero round trip time resumption; 800 Million: tons of prey eaten by spiders; 90%: accuracy of quantum computer recognizing trees; 80 GB/s: S3 across 2800 simultaneous functions;

  • Quotable Quotes:
    • @GossiTheDog: Here's something to add to your security threat model: backups. Why steal live data and when you can drive away with exact replica?
    • @ThePublicSquare: "California produces 160% of its 1990 manufacturing, but with just 60% of the workers." -@uclaanderson economist Jerry Nickelsburg
    • @rbranson: makes total sense. I have a friend (who is VC-backed) that has stuff in Azure, GCloud, and AWS to maximize the free credits.
    • @AndrewYNg: If not for US govt funding (DARPA, NSF), US wouldn't be an AI leader today. Proposed cuts to science is big step in wrong direction.
    • @CodeWisdom: "To understand a program you must become both the machine and the program." - Alan Perlis 
    • @codemanship: What does it take to achieve Continuous Delivery? 1. Continuous testing. e.g., Google have 4.2M automated tests, run avg of 35x a day
    • @sebastianstadil: Azure Storage services are down. They really are doing everything like AWS.
Categories: Architecture

Becoming an Agile Leader, Part 4: Determining Next Steps

To summarize: your agile transformation is stuck. You‚Äôve¬†thought about your why, as in¬†Becoming an Agile Leader, Part 1: Define Your Why.¬†You‚Äôve started to measure possibilities. You have an idea of who you might talk with as in¬†Becoming an Agile Leader, Part 2: Who to Approach.¬†You’ve considered¬†who you need as allies and how to enlist them in Becoming an Agile Leader, Part 3: How to Create Allies.

Now, it’s time to think about what you will do next.

You might be thinking, “I know what to do next. I have a roadmap, I know where we want to be. What are you talking about?”

Influence. I’m talking about thinking about discovering the short-term and longer-term actions that will help your agile transformation succeed with the people who hold the keys to your transformation.

Here’s an example. Patrick (not his real name) wanted to help his organization’s agile transformation. When he came to the Influential Agile Leader, that was his goal: help the transformation. That’s one big goal. By the time we got to the influence section, he realized his goal was too big.

What did he want, right now? He was working with one team who wrote technical stories, had trouble getting to done, didn’t demo or retrospect, and wanted to increase the length of their iteration to four weeks from two weeks. He knew that was probably going in the wrong direction. (There are times when it’s okay to increase the length of the iteration. This team had so much change and push for more delivery, increasing the time was not a good option.)

He thought he had problems in the management. He did, but those weren’t the problems in the team. When he reviewed his why and his map, as in Part 1, he realized that the organization needed an agile approach for frequent delivery of customer value. If this team (and several others) could release value on a regular basis, the pressure from the customers and management would lessen. He could work with the managers on the project portfolio and other management problems. But, he was sure that the way to make this happen was to help this team deliver frequently.

He realized he had two influential people to work with: the architect and the QA lead. Both of those people looked as if they were “resisting.” In reality, the architect wanted the developers to refactor to patterns to keep the code base clean. The QA lead thought they needed plans before creating tests and was looking for the “perfect” test automation tool.

He decided that his specific goal was to “Help this team deliver value at least as often as every two weeks. Sustain that delivery over six months.” That goal—a subset of “go agile”—allowed him to work first with the architect and then with the QA lead and then both (yes, he practiced all three conversations in the workshop) to achieve his small goal.

Patrick practiced exploring the short-term and long-term deliverables in conversations in the workshop. While the conversations didn’t go precisely the same way back at work, he had enough practice to move between influence and coaching to see what he could do with the people in his context.

It took the team three more iterations to start delivering small stories, but they did. He spent time enlisting the architect in working in the team with the team members to deliver small stories that kept the code base clean. He asked the architect for help in how to work with the QA lead. The architect showed the lead how to start automation and refactor so the testers could test even before the developers had completed the code.

It took that team three more months to be able to regularly deliver value every week, without waiting for the end of the iteration.

Patrick’s original roadmap was great. And, once he started working with teams and management, he needed to adjust the deliverables he and the other coaches had originally planned. The influence conversations allowed him to see the other people’s concerns, and consider what small deliverables all along the way would help this team succeed.

Some of what he learned with this team helped the other teams. And, the other teams had different problems. He used different coaching and influence conversations with different people.

If you want to experience learning how to influence and who, in the context of helping your agile transformation continue, join us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.

My next post is about our participants learn.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Fri, 03/17/2017 - 05:59

If you don’t pay appropriate attention to what has your attention, it will take more of your attention than it deserves. 
‚ÄĒ David Allen, Consultant

Since all project work is uncertain, both reducible and irreducible randomness, we need to pay attention to the root causes and outcomes that impact the probability of our project's success. To make decisions on how the handle the risk created by this uncertainty, we need to estimate both the drives of this risk and the consequences of the risk. 

Screen Shot 2017-03-16 at 6.27.47 AM

Risk Management is How Adults Manage Projects - Tim Lister

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Managing in Presence of Uncertainty Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter Managing Projects By The Numbers Strategy is Not the Same as Operational Effectiveness
Categories: Project Management

Three Requirements for Effective Incremental Change

26369190215_3972c2acce_k

People involved with conceiving, directing and coaching change overwhelmingly favor incremental change methods.  The support for incrementalism always comes with caveats.  Those caveats can be consolidated into three requirements. Organizations with effective incremental change programs are pursuing a vision, have an appreciation for the need to increase tolerance to change, and embrace innovation.

A vision that describes a future state in which the business problem is solved is the most critical requirement for effective incremental change. The vision provides direction to the participants in the effort by providing a goal for the team to progress toward. ¬†Each incremental change can be compared to the expressed vision so we can tell whether we are on the correct path. ¬†Dominque Bourget, The Process Philosopher, provided the following quote to drive the point home (PS ‚Äď it sounds very cool in Canadian French, just ask him):

In real estate there are 3 important things: location, location, and location.
In software development there are 3 important things: quality, quality, and QUALITY.
In process improvement there are 3 dangerous things: short view, short view, and short view.‚ÄĚ

The second an appreciation for the need to increase tolerance to change. ¬†The incremental change means that how work is done will be in a continual state of flux. ¬†Early in my career, a mentor suggested that people and organizations really don‚Äôt like change.¬†Therefore, it was important to give people the feeling of stability. Over time I have developed a more nuanced understanding of the message about change. ¬†People tend not to like changes they perceive to be harmful and embrace changes they believe will be positive for them and/or that they have a hand in shaping. ¬†An incremental change approach that involves those affected will foster higher levels of tolerance to change. ¬†D√°cil Castelo, Productivity & Estimation Area Director at LEDAmc, summarized why she prefers incremental change: ‚Äúthe resistance to change is less with incremental change.‚ÄĚ

The third requirement to effective incremental change approach is the need to embrace innovation. All process improvement requires innovation; however, incremental change approaches generally require more innovative approaches in order to preserve momentum. ¬†Incremental change is rarely as straightforward as slicing up larger projects into parts. ¬†Innovation, by definition, represents a substantial deviation from the thought processes of the past. ¬†The power of doing much smaller, related changes is that you receive faster feedback. ¬†Faster feedback generates the need for more agility from those guiding or championing a change initiative as they adapt to changes in the environment. ¬†¬†To paraphrase Helmuth von Moltke, ‚Äúno plan survives contact with the enemy.‚ÄĚ In incremental change approaches contact happens over and over hence the need for innovation.

While I agree with the Process Philosopher that a consistent vision is the most important requirement for effective incremental change, but it is not sufficient. Without an approach to deal with change fatigue, often called change management, almost every change program will fail.  Even good change management support won’t suffice without innovation that integrates the feedback generated as people use those changes.  All three requirements must be addressed!


Categories: Process Management